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ABSTRACT 


Line-of*sight  (LOS)  calculation  for  the  Janus  combat  simulation  model  is  critical  to 
the  processes  being  simulated  and  impacts  the  run  speed  (ratio  of  game  time  to  real  time), 
since  it  may  be  the  single  most  computationally  expensive  algorithm  in  simulation. 

This  thesis  presents  design  and  implementation  of  a  transputer  network  with  the 
purpose  of  providing  an  efficient  LOS  calculation  in  a  distributed  memory  and  computing 
environment.  The  approach  taken  was  to  use  a  processor  farming  method  to  speed  up  the 
LOS  calculation.  The  programs  were  implemented  on  a  network  of  IS  transputers  using  3L 
Parallel  C++  (version  2.1.1)  programming  language.  A  1 -meter  resolution  terrain  database 
of  Fort  Hunter  Liggett,  California  was  used  to  get  more  reliable  LOS  results. 

Expected  gain  of  our  system  was  3.873  (VTs).  After  timing  tests,  we  found  that  we 
could  speed  up  the  LOS  calculation  by  a  factor  of  2.581  when  comparing  the  IS  transputer 
configuration  to  a  conventional  processor  which  is  equivalent  to  a  single  transputer.  The 
difference  between  expected  gain  and  actual  gain  was  found  to  be  the  communication 
overhead  in  the  network  of  transputers.  We  stated  that  further  significant  improvements  can 
be  provided  by  using  our  approach  with  more  memory  and  faster  transputers. 
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DEDICATION 


I  dedicate  my  thesis  to  my  parents  Nimet  and  Ahmet  DQndar  who  were  my  first  teachers 
and  of  whom  I’m  very  proud  to  be  their  son. 


I.  INTRODUCTION 


A.  BACKGROUND 

1.  Janus 

The  Janus  simulation  was  fielded  in  1978  [Ref.  1].  It  was  developed  as  a  nuclear 
effects  modeling  tool  by  Lawrence  Livennore  National  Laboratories  and  became  known  as 
Janus(L).  TRADOC  Analysis  Command  (TRAC)  at  White  Sands  Missile  Range  (WSMR) 
modified  Janus(L)  to  meet  Army  combat  development  needs.  The  modified  Janus(L) 
model  became  known  as  Janus(T).  The  Army  realized  the  value  of  the  system  for  use  in  the 
training  arena,  and  tasked  TRAC-WSMR  with  developing  a  multipurpose  system  from  the 
best  of  Janus(L)  and  Janus(T),  which  was  termed  Janus(A).  Through  enhancements  and 
upgrades,  Janus(A)  has  reached  a  version  level  of  4.0  as  of  January  1994. 

The  Janus  model  simulates  battle  between  Blue  and  Red  units.  It  supports  conflict 
from  individual  systems  and  company-sized  units  through  biigadeAegimental-sized  units. 
It  is  an  interactive,  two-sidco,  closed,  stochastic,  ground  combat  simulation  featuring 
precise  color  graphics.  Janus  is  “interactive”  in  that  the  command  and  control  functions  arc 
entered  on  workstations  by  rrulitary  analysts  who  decide  what  to  do  in  crucial  situations 
during  simulated  combat.  “Two-sided”  refers  to  the  two  opposing  forces,  blue  and  red, 
directed  simultaneously  by  two  sets  of  players.  “Closed”  means  that  the  disposition  of 
opposing  forces  is  largely  unknown  to  the  players  in  control  of  the  other  force.  “Stochasuc” 
refers  to  the  way  the  system  determines  the  results  of  actions  such  as  direct  fire 
engagements;  according  to  the  laws  of  probability  and  chance.  “Ground  combat”  means 
that  the  principal  focus  is  on  ground  maneuver  and  artillery  units,  although  Janus  also 
models  weather  and  its  effects,  day  and  night  visibility,  engineer  support,  minefield 
employment  and  breaching,  votary  and  fixed  wing  aircraft,  resupply  and  a  chemical 
environment.  Janus  is  an  event-driven  simulation. 
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2.  The  Transputer 

The  term  “transputer”  is  an  acronym  for  “transistor  computer”  where  it  reflects 
the  ability  of  this  device  to  be  used  as  a  system’s  building  block,  much  like  the  transistor 
was  in  the  past  [Ref.  2].  The  nice  feature  of  the  transputer  is  that  it  adds  a  new  level  of 
abstraction,  which  provides  a  very  simple  way  to  design  a  concurrent  system.  As  a  formal 
definition  we  could  state  that  the  transputer  is  a  single-chip  microcomputer  that  has  its  own 
local  memory  and  four  communication  links.  The  links  may  be  thought  as  of  as  small 
special  purpose  processors  which  steal  no  cycles  from  the  main  CPU,  in  such  a  way  that  we 
could  have  ail  four  links  and  the  CPU  working  at  the  same  time,  without  degrading  the 
performance  of  the  program’s  execution. 

The  transputer  is  a  parallel  microprocessor,  generally  categorized  as  a  Multiple 
Instruction  Multiple  Data  (MIMD)  computer  [Ref.  3]  [Ref.  4:pp.  498-500].  This  means  that 
transputers  are  used  to  execute  difl^erent  operations  on  separate  data  at  the  same  tinte.  This 
is  somewhat  like  a  football  team  where  individual  players  execute  their  own  special 
assignments  together  during  a  play.  A  transputer  operates  as  a  stand-alone  machine  or  as  a 
processing  element  interconnected  by  their  links  to  form  computing  arrays  and  networks. 
Modular  design  enables  transputers  to  be  used  together  in  arbitrary  numbers  to  support  a 
broad  range  of  applications,  and  the  inherit  redundancy  of  multiprocessing  can  be  utilized 
for  fault  tolerance. 

B.  SCOPE  OF  THESIS 

Linc-of-sight  (LOS)  is  a  central  process  in  combat  simulations  that  works  at  item 
level,  llte  LOS  algorithm  is  critical  to  the  processes  being  simulated  and  impacts  the  run 
speed  (ratio  of  game  time  to  real  time),  since  it  may  be  the  single  most  computationally 
expensive  algorithm  in  the  simulation. 

This  study  is  focused  specifically  on  the  following  two  objectives: 
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1 .  To  implement  an  efficient  calculation  of  LOS  in  a  distributed  memory  environment 
by  using  transputers  and  1  •meter  resolution  terrain  database. 

2.  To  show  that  the  usage  of  1 -meter  resolution  terrain  database  for  LOS  calculation 
purposes  gives  more  precise  and  reliable  results  than  the  current  SO  or  100-meter  resolution 
terrain  databases. 

C.  THESIS  ORGANIZATION 

This  thesis  is  presented  in  six  chapters  and  three  appendices. 

Chapter  1  is  the  introduction  to  the  problem  and  the  background  for  Janus  combat 
simulation  system  and  the  transputer. 

Chapter  II  describes  the  current  issues  about  parallel  computing  vrith  transputers. 

Chapter  III  presents  a  detailed  problem  statement  for  this  thesis.  The  current  issues 
about  Janus  which  are  PEGASUS  tenain  database  organization  and  the  algorithm  for  LOS 
calculation  are  described  in  this  chapter. 

Chapter  IV  describes  the  transputer  implementation  of  LOS  calculation  in  both 
hardware  and  software  aspects. 

Chapter  V  presents  the  experimental  results  of  the  transputer  implementation  of  LOS 
calculation. 

Chapter  VI  states  the  conclusions  and  recommendations  for  further  research. 

Appendix  A  includes  the  Sun  SPARC  Station  source  code. 

Appendix  B  includes  the  Host  Computer  (PC)  source  code. 

Appendix  C  includes  the  source  code  for  reading  terrain  data  from  Pegasus  Database. 
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IL  TRANSPUTERS  AND  PARALLEL  COMPUTING 


A.  PARALLELISM 

In  the  first  computing  wave,  scientific  and  business  computers  were  more  or  less 
identical  as  they  were  all  big  and  slow  [Ref.  6:p.  1].  Even  the  early  electronic  computers 
were  not  very  fast.  This  was  the  “prehistory  of  computing”,  where  computing  had  to  be 
employed  at  any  cost. 

The  second  and  third  waves  brought  on  mainframes,  minis,  and  finally  micros.  This 
diversity  of  computing  caused  a  number  of  niches  to  develop  which  broadened  and 
deepened  the  computer  industry.  Scientific  and  business  computing  went  their  separate 
ways,  and  there  seemed  to  be  a  computer  in  just  about  everyone's  pnee  i 

But  the  original  power  users  who  pioneered  computing  continued  to  emphasize  speed 
above  all  else.  Single-processor  supercomputers  achieved  unheard  of  speeds  beyond  100 
million  instructions  per  second,  and  pushed  hardware  technology  to  the  physical  limits  of 
chip  building.  But  soon  this  trend  will  come  an  end,  because  there  are  physical  and 
architectural  bounds  which  limit  the  computational  power  that  can  be  achieved  with  a 
single-processor  system. 

We  are  now  enjoying  the  Parallel  Wave  [Ref.  6:pp.  1-5]  of  computing,  where 
performance  is  enhanced  by  using  multiple  processors.  Parallelism  is  the  process  of 
performing  tasks  concurrenUy.  It  has  been  touted  as  a  solution  to  the  problem  of  making 
computers  faster  and  faster.  When  the  physical  limits  for  single-processor  systems  are 
reached,  parallelism  will  be  the  only  course.  However,  even  before  the  speed  limit  is 
reached,  there  is  an  economic  motivation  to  use  parallel  processing  in  place  of  faster  and 
more  expensive  single-processor  systems.  Indeed,  the  economic  advantage  of  low-cost, 
multiple  processing  systems  was  realized  in  the  mid-1980s.  Hence,  the  1990s  were  poised 
for  the  decade  of  parallelism  simply  due  to  economic  forces. 
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Many  parallel  architectures  have  been  discussed  in  the  past,  and  there  are  several 
superminicomputer  parallel  systems  available  today.  However,  most  of  these  are  unable  to 
provide  the  very  wide  range  of  price^>eTformance  that  parallel  processing  promises  and  that 
transputer-based  systems  can  provide  [Ref.  SJ. 

To  understand  this,  it  is  worth  examining  the  normal  approach  to  parallel  systems 
design.  Most  parallel  systems  are  constructed  by  connecting  up  multiple  computers  with  a 
single  high  speed  bus.  A  simplified  system  can  be  imagined,  consisting  of  multiple 
processors  sharing  a  single  global  memory  accessed  via  a  single  high  performance  bus. 

This  shape  of  system  will  provide  very  disappointing  results  for  obvious  reasons;  a 
processor  can  only  access  memory  when  no  other  processor  is  accessing  memory.  With 
high  performance  processors,  this  will  provide  an  rmer  limit  of  perhaps  two  or  three 
processors  before  performance  stops  inaeasing.  i  ns  po^s.i  le  to  speed  the  system  up,  but 
only  by  use  of  memory  that  is  very  much  faster  that  u  .*  pro  rc^sors.  This  is  expensive. 

In  more  realistic  system  each  processor  has  some  privaic,  local  memory  in  addition 
to  bus  access  to  global  memory.  The  local  memory  could  be  organized  as  either  a  private 
address  space,  or  a  sufficiently  large  cache.  Now,  it  is  possible  to  imagine  a  system  where 
a  processor  spends  perhaps  90%  of  its  time  accessing  local  memory  and  only  10% 
accessing  the  shared  store.  Then  with  reasonably-priced  memory  it  should  be  possible  to 
build  a  computer  which  can  use  perhaps  twenty  or  thirty  processors  before  saturating. 

The  bottleneck  in  this  system  is  the  shared  resource,  either  the  bus  or  the  memory. 
The  bus  itself  is  a  poor  choice  for  interconnect  in  any  case;  not  only  does  its  logical 
performance  degrade  as  more  processors  contend  for  it,  the  extra  electrical  loads  imposed 
by  adding  processors  to  the  bus  either  slow  the  system  down  as  more  machines  are  added, 
or  set  a  much  lower  bandwidth  on  the  bus  for  lower  processor  counts. 

Whichever  is  the  bottleneck  at  present,  the  apparently  inexorable  improvement  in 
semiconductor  technology  will  arrange  for  it  to  be  the  bus  since  affordable  memory  and 
processor  speeds  are  increasing  faster  than  unproved  backplane  technologies.  As  a  result, 
this  sort  of  system  is  guaranteed  non-futme  proof;  as  device  speeds  increase,  the  system 
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performancr.  flattens  out  since  the  maximum  number  of  processors  usable  before  bus 
saturation  reduces  with  time. 

The  system  architecture  can  be  changed  slightly  to  remove  the  straitjacket  imposed 
by  the  bus.  An  obvious  improvement  is  to  use  multiple  buses,  probably  arranged  in  some 
regular,  structured  maimer,  like  a  hierarchy.  Now,  clusters  of  computers,  each  with  its  own 
local  memory,  share  some  cluster  memory  via  a  cluster  bus.  Clusters  are  coimected  by  other 
buses;  these  buses  themselves  can  have  memory.  Then,  assuming  that  90%  of  accesses  are 
local,  and  that  90%  of  the  non-local  accesses  are  to  the  local  cluster  shared  memory,  the 
earlier  arguments  suggest  that  for  a  well-behaved  problem,  a  twenty  cluster  system  could 
be  built,  with  each  cluster  having  twenty  processors. 

This  solution  should  work  for  a  range  of  applicatioitS,  but  the  amount  of  logic  and 
intercoimect  needed  to  implement  it  makes  it  expensive.  It  has  another  problem,  too;  while 
it  is  an  acceptable  architecture  for  a  single,  centralized  computer,  shared  buses  do  not  seem 
to  be  an  appropriate  paradigm  for  distributed  parallel  systems. 

These  criticisms  can  be  resolved  by  a  small  change  in  attitude  to  the  system 
architecture,  and  then  a  re-implementation.  Assume  that  the  system  is  an  actual  parallel 
computing  system,  rather  than  just  a  collection  of  computers  each  with  access  to  some 
shared  system  resource;  then  the  processors  must  be  interacting  with  one  another.  Each  will 
be  working  on  a  portion  of  the  problem,  and  will  interchange  partial  results  with  other 
processors  as  they  jointly  progress  toward  completing  the  program.  To  do  this,  each 
machine  will  likely  provide  the  equivalent  of  mailboxes,  where  the  other  processors  can 
leave  their  own  results  and  their  requests  for  information. 

But  if  the  processors  are  cooperating  by  exchanging  messages,  then  there  is  no  need 
to  use  shared  menwry  to  implement  the  communication.  Instead,  direct  interprocessor  data 
transfer  channels  can  be  used  to  Direct  Memory  Access  (DMA)  (Ref.  4:pp.  297-301) 
information  from  one  processor  to  another.  Given  such  a  mechanism,  we  cure  several 
problems  at  once;  a.*;  we  add  processors,  we  add  interprocessor  bandwidth;  the  processors 
do  not  need  to  be  physically  located  together,  and  so  can  be  components  of  a  distributed 
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system  without  necessarily  altering  the  system  design  or  software;  and  the  cost  of  the 
interprocessor  hardware  can  be  much  reduced  from  bus  costs  (since,  for  example,  there  is 
no  need  for  an  address,  we  can  save  by  not  having  address  lines;  since  there  is  exactly  one 
destination  for  each  driver,  the  electrical  design  is  simpler). 

This  is  the  system  architecture  chosen  for  the  transputer.  Each  transputer  comes  with 
one  or  more  interprocessor  links,  each  one  DMA-driven  to  ensure  that  communication  can 
take  place  in  parallel  with  computation.  Transputers  further  reduce  system  cost  by  using 
serial  interconnect;  minimizing  pin  count  reduces  transputer  cost  and  interconnect  cost, 
e?.ses  board  layout  and  minimizes  power  consumption. 

B.  THE  INMOS  TRANSPUTER 

The  transputer  (Ref.  7:pp.  7-30]  was  developed  by  INMOS  Limited  of  Bristol,  United 
Kingdom,  and  has  since  expanded  into  a  family  of  very  large  scale  integrated  (VLSI) 
components  with  different  capabilities.  Since  the  transputer  is  a  component  designed  to 
exploit  the  potential  of  VLSI,  that  technology  allows  large  numbers  of  identical  devices  to 
be  manufactured  cheaply.  For  this  reason,  it  is  attractive  to  implement  a  concurrent  system 
using  a  number  of  identical  components,  each  of  which  is  customized  by  an  appropriate 
program.  The  revolutionary  architecture  of  the  transputer  enables  the  potential  of 
concurrency  to  be  reaUzed  for  the  fust  time,  making  today’s  applications  easier  to 
implement  and  creating  a  new  dimension  for  tomorrow’s  systems. 

The  transputer  uses  silicon  capability  to  make  programming  simpler  and  to  make 
engineering  easier  than  for  any  previous  microprocessor.  The  architecture  has  been 
optimized  to  obtain  the  maximum  of  functionality  for  the  minimum  of  silicon.  It  allows 
different  trade  offs  between  performance  and  cost,  always  giving  an  intrinsic  advantage 
over  older  architectures.  The  architecture  is  future*  proof.  It  spans  the  range  of 
applications  from  microcontrollers  to  supercomputers.  Transputers  will  exploit  future 
levels  of  integration  by  increasing  the  amount  of  processing,  mennory,  communications  and 
concurrency  within  the  same  architeenue. 
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A  typical  member  of  the  transputer  family  is  a  single  chip  containing  processor, 
memory,  and  communication  links  which  provide  point  to  point  connection  between 
transputers.  The  transputer  provides  a  direct  implementation  of  the  process  model  of 
computing.  A  process  is  an  independent  computation,  with  its  own  program  and  data, 
which  can  communicate  with  other  processes  executing  at  the  same  time.  Communication 
is  by  message  passing,  using  explicitly  defined  channels. 

The  transputer  is  designed  so  that  it  can  implement  a  set  of  concurrent  processes. 
Special  instructions  share  the  proce.ssor  time  between  the  concurrent  processes  and  perform 
interprocess  communication. 

In  addition,  the  transputer  is  designed  so  that  its  external  behavior  corresponds  to  the 
formal  model  of  a  process.  As  a  consequence,  it  is  possible  to  program  systems  contaiiung 
multiple  interconnected  transputers  in  which  each  transputer  implements  a  set  of  processes. 
Since  a  program  is  defined  as  a  set  of  processes,  it  can  be  mapped  onto  such  a  system  in  a 
variety  of  ways,  such  as  minimizing  cost,  or  optimizing  throughput,  or  maximizing  the 
responsiveness  to  specific  events. 

The  transputer  specifically  implements  the  concept  of  communicating  sequential 
processes  (CSP)  defmed  by  C.A.R.  Hoare  [Ref.  8]  and  to  be  used  as  a  building  block  for 
distributed  computing  systems.  The  CSP  concept  describes  the  interactions  between 
programs  that  execute  in  parallel. 

1.  Communicating  Sequential  Processes 

Hoaie’s  Communicating  Sequential  Processes  (CSP)  is  one  model  for  concunent 
or  parallel  programming,  and  it  is  central  to  the  design  of  the  transputer.  In  CSP,  a  program 
is  a  collection  of  processes  which  can  be  combined  to  execute  sequentially  on  a  single 
processor  or  in  parallel  on  multiple  processors.The  data  space  for  any  process  executing  in 
parallel  is  disjoint,  thus  alleviating  the  need  for  sharing  memory  between  processors. 
Although  shared  memory  is  not  available,  processes  must  still  communicate  with  each 
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other.  Therefore,  CSP  utilizes  message  passing  between  any  pair  of  parallel  processes  via 
declared  communication  channels  between  two  processes. 

In  order  for  the  concurrent  processes  to  conununicate,  message  passing  must  be 
synchronized.  Such  communication  occurs  when  one  process  names  another  as  destination 
for  output  and  the  second  process  names  the  first  as  source  for  input  This  allows  the  value 
tc  be  ou^ut  by  the  source  process  to  be  copied  into  the  destination  process.  Note  that  the 
synchronization  imposes  a  requirement  that  an  output  (input)  command  must  be  delayed 
until  the  corresponding  input  (output)  command  in  the  other  process  is  ready  to  be 
executed. 

2.  Transputer  Architecture 

Several  versions  of  the  transputer  are  currently  available.  This  thesis  considers 

transputer  types  IMS  T800  and  IMS  T805*.  The  following  sections  describe  the  features  of 
an  IMS  T800  20MHz  transputer.  A  complete  description  of  all  currently  available 
transputers  can  be  found  in  [Ref.  7]  and  [Ref.  9].  A  block  diagram  of  an  IMS  T800 
transputer  is  shown  in  Figure  2.1. 

e.  Overall 

The  IMS  T800  is  a  64  bit  floating  point  member  of  a  family  of  transputers,  all 
which  are  consistent  with  the  INMOS  transputer  architecture.  It  integrates  a  32  bit 
microprocessor,  a  64  bit  floating  point  unit,  four  standard  transputer  communication  links, 
4Kbytcs  on-chip  RAM  for  high  speed  processing,  a  configurable  memory  interface  and 
peripheral  interfacing  on  a  single  chip,  using  a  1.5  micron  CMOS  process. 


1 .  T805  is  a  new  version  of  T800.  They  are  essentially  same  processors  and  our  lab  has  a  mixture  of 
T800  and  T80S  transputers. 
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Figure  2.1:  IMS  T800  Block  Diagram  of  the  32>bit  IVansputer 
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b.  Central  Processor 

The  32  bit  processor  provides  10  MIPs  performance.  The  design  achieves 
compact  programs,  efficient  high  level  language  implementation  and  provides  direct 
support  for  the  occam  (a  programming  language  that  will  be  mentioned  later)  model  of 
concurrency.  Procedure  calls,  process  switching  and  interrupt  latency  are  all  sub¬ 
microsecond.  The  processor  shares  its  dme  between  any  number  of  concurrent  processes. 
A  process  waiting  for  communication  or  a  timer  does  not  consume  any  processor  time.  Two 
levels  of  process  priority  enable  fast  interrupt  response  to  be  achieved. 

c.  Floating  Point  Unit 

The  64  bit  floating  point  unit  provides  single  length  and  double  length 
operation  according  to  the  ANSI-IEEE  7S4-198S  standard  for  floating  point  arithmetic  and 
able  to  perform  floating  point  arithmetic  operations  concurrently  with  the  processor; 
sustaining  in  excess  of  l.S  Mega  Flops. 

The  floating  point  unit  (FPU)  on  the  T800  consists  of  a  microcoded 
computing  engine  which  operates  concurrently  with  and  under  the  control  of  the  Central 
Processing  Unit  (CPU).  It  contains  a  three  deep  floating  point  evaluation  stack  on  which 
floating  point  numbers,  represented  in  the  IEEE  format  can  be  manipulated.  All  data 
communication  between  memory  and  the  floating  point  unit  is  done  under  the  control  of 
the  CPU. 

d.  Memory  System 

The  4Kbytes  of  on  chip  static  RAM  provide  a  maximum  data  rate  of  80 
Mbytcs/sec  with  access  for  both  the  processor  and  links.  The  IMS  T800  can  directly  access 
a  linear  space  up  to  4  Gbytes.  The  32  bit  wide  external  memory  interface  uses  multiplexed 
data  and  address  lines  provides  a  data  rate  up  to  26.6  Mbytes/sec.  A  configurable  memory 
controller  provides  all  timing,  control  and  DRAM  refresh  signals  for  a  wide  variety  of 
memory  systems.  Internal  and  external  memory  appear  as  a  single  continuous  address 
space. 
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e.  Links 

The  IMS  T800  uses  a  DMA  block  transfer  mechanism  to  transfer  messages 
between  memory  and  another  transputer  product  via  the  INMOS  links.  The  link  interfaces 
and  the  processor  all  operate  concurrently,  allowing  processing  to  continue  while  data  is 
being  transferred  on  all  of  the  links. 

The  four  standard  INMOS  serial  links  on  the  IMS  T800  give  a  unidirectional 
transmitted  data  rate  of  1.7  Mbytes/sec  and  a  combined  (bidirectional)  data  rate  per  link  of 
2.3  Mbytes/sec,  at  a  link  speed  of  20  Mbits/sec.  Link  speeds  of  10  Mbits/sec  and  a  5  Mbits/ 
sec  are  also  available  on  the  IMS  T800  making  the  device  compatible  with  all  other  INMOS 
transputer  products. 

f.  Peripheral  Interface 

The  memory  controller  supports  memory  mapped  peripherals,  which  may  use 
DMA.  Links  may  be  interfaced  to  peripherals  via  an  INMOS  link  adaptor.  A  peripheral  can 
request  attention  via  the  event  pin. 

g.  Error  Handling 

High-level  language  execution  is  made  secure  with  array  bounds  checking, 
arithmetic  overflow  detection  etc.  A  flag  is  set  when  an  error  is  detected.  The  error  can  be 
handled  internally  by  software  or  externally  by  sensing  the  error  pin. 

h.  Programming  IMS  T800 

The  IMS  T8{X)  transputer  can  be  programmed  in  several  languages  including 
Occam,  C,  C-h-,  Ada,  Fortran  and  Pascal. 

L  Processes  And  Concurrency 

The  transputer  provides  direct  support  for  concurrency.  It  has  a  microcoded 
scheduler  which  enables  any  number  of  concurrent  processes  to  be  executed  together, 
sharing  the  processing  time.  Tnis  removes  the  need  for  a  software  kernel. 
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A  process  starts,  performs  a  number  of  actions,  and  then  either  stops  without 
completing  or  terminates  complete.  Typically,  a  process  is  a  sequence  of  instructions.  A 

transputer  can  run  several  processes  concurrently^.  Processes  may  be  assigned  either  high 
or  low  priority,  and  there  may  be  any  number  of  each. 

At  any  time,  a  concurrent  process  may  be 

Active  '  Being  executed 

-  On  a  list  waiting  to  be  executed. 

Inactive  •  Ready  to  input 

•  Ready  to  output 

-  Waiting  until  a  specified  time. 

The  scheduler  operates  in  such  a  way  that  inactive  processes  do  not  consume 
any  processor  dme.  It  allocates  a  portion  of  the  processor’s  time  to  each  process  in  turn. 
Each  process  runs  until  it  has  completed  its  action,  but  is  desch?duled  while  waiting  for 
conununication  from  another  process  or  transputer,  or  for  a  time  delay  to  complete. 

j.  Priority 

The  IMS  T800  supports  two  levels  of  priority.  Priority  1  (low  priority) 
processes  are  executed  whenever  there  are  no  active  priority  0  (high  priority)  processes. 

High  priority  processes  are  expected  to  execute  for  a  short  time.  If  one  or  more 
high  priority  processes  are  able  to  proceed,  then  one  is  selected  and  runs  until  it  has  to  wait 
for  a  communication,  a  timer  input,  or  until  it  completes  processing.  If  no  process  at  high 
priority  is  able  to  proceed,  but  one  or  more  processes  at  low  priority  are  able  to  proceed 
then  one  is  selected.  Low  priority  processes  are  periodically  timesliced  to  provide  an  even 
distribution  of  processor  time  between  computationally  intensive  tasks. 

Note  that  the  intention  of  having  two  priority  levels  for  processes  is  to  allow 
those  high  priority  tasks,  which  must  be  executed  when  they  are  invoked,  to  preempt  a 
currendy  executing  low  priority  process  and  execute  to  completion.  It  is  important  that  the 

2.  This  is  actually  a  time-sharing  for  a  single  CPU  system. 
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high  priority  tasks  have  a  very  short  execution  time  (less  than  one  slicetime  period). 
Otherwise  tne  low  priority  processes,  which  should  be  the  computation  intensive  processes, 
will  not  be  given  fair  access  to  the  processor. 

k.  Communications 

Communications  between  processes  is  achieved  by  means  of  channels. 
Process  conununication  is  point-to-point,  synchronized  and  unbuffered.  As  a  result,  a 
channel  needs  no  process  queue,  no  message  queue  and  no  message  buffer. 

A  channel  between  two  processes  executing  on  the  same  transputer  is 
implemented  by  a  single  word  in  naemory;  a  channel  between  proc  ises  executing  on 
different  transputers  is  implemented  by  point-to-point  links.  The  processor  provides  a 
number  of  operations  to  support  message  passing,  the  most  important  being  input  message 
and  output  message. 

The  input  message  and  output  message  instructions  use  the  address  of  the 
channel  to  determine  whether  the  chaiuiel  is  internal  or  external.  Thus  the  same  instruction 
sequence  can  be  used  for  both,  allowing  a  process  to  be  written  and  compiled  without  the 
knowledge  of  where  its  channels  are  connected. 

The  piocess  which  first  becomes  ready  must  wait  until  the  second  one  is  also 
ready.  A  process  performs  an  input  or  output  by  loading  the  evaluation  stack  with  a  pointer 
to  a  message,  the  address  of  a  channel,  and  a  count  of  the  number  of  bytes  to  be  transferred, 
and  then  executing  an  input  message  or  output  message  instruction.  Data  is  transferred  if 
the  other  process  is  ready.  If  the  channel  is  not  ready  or  is  an  external  one  the  process  will 
deschedule. 

3.  Programming  Languages 

There  are  several  languages  which  can  be  used  to  write  programs  for  use  on  the 
transputer.  Among  these  arc  Occam,  Alsys-Ada,  3L’s  Parallel  C,  C-H-,  Pascal  and  Fortran. 
Three  of  the  languages  were  considered  for  this  thesis.  These  three  languages  were  Occam 
[Ref.  10],  Alsys-Ada  (Ref.  11],  and  3L’s  Parallel  C++  (Ref.  12]  [Ref.  13]. 
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a.  Occam  Programming  Language 

Occam  [Ref.  10]  is  a  high  level  programming  language  that  is  designed  to  run 
concurrent  processes  on  a  network  of  processing  components  (e.g.  transputers).  There  are 
two  prime  concepts  in  Occam;  they  arc  concurrency  and  communication.  These  allow 
processes  to  run  simultaneously  and  transfer  information,  via  channels,  from  process  to 
process.  It  is  based  on  concepts  founded  by  David  May  in  Experimental  Programming 
Language  and  Tony  Hoarc  in  Communicating  Sequential  Processes. 

It  allows  processes  running  on  a  transputer  system  to  communicate  only 
through  channels.  These  chaiuiels  arc  asynchionous,  but  require  the  send  and  receive 
processes  to  be  ready  to  send  and  receive  at  the  same  time.  This  idea  of  being  ready  to  send 
and  receive  simultaneously  is  known  as  rendezvous. 

Occam  has  five  kinds  of  constructions  that  arc  used  to  build  a  process  from 
smaller  processes  (primitive  or  other).  These  constructions  arc: 

-  IF:  This  construction  guards  a  number  of  processes  by  a  boolean  expression. 

-  CASE:  This  construction  is  used  to  select  zt\t  of  a  number  of  options. 

-  WHILE:  This  construction  is  used  for  loops. 

-  PAR:  This  construction  has  the  effect  of  allowing  the  processes  within  its 
bounds  to  execute  in  parallel. 

-  ALT:  This  construction  is  used  to  allow  a  processor  to  select  only  one  of 
several  guarded  processes  for  execution.  The  process  whose  guard  ts  fust  found  to  be  true 
is  selected 

This  language  allows  the  programmer  to  concentrate  on  a  small,  manageable 
set  of  processes  which  can  then  be  connected  with  other  sets  of  processes.  In  Occam  a  set 
of  processes  or  a  set  of  interconnected  processes  can  oe  regarded  as  a  single  process. 

The  above  features  make  Occam  a  powe,  ful  and  versatile  language,  .t  has  not 
gained  wide  acceptance  thus  far  probably  due  to  the  limited  use  of  multiprocessor 
(transputer)  systems  and  due  to  the  development  of  parallel  versions  of  other  widely  used 
languages. 
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b.  Alsys  Ada  Programming  Language 


In  October  1989,  Alsys  produced  the  Hrst  compiler  capable  of  supporting 
multi-processor  programming  in  Ada  [Ref.  1 1].  Alsys  Ada  Compilation  System  consists  of 
the  compiler  and  binder,  operating  in  the  Alsys  Multi-Library  Environment  The  compiler 
generates  executable  code  for  transputer  for  T4  or  T8  transputer  targets.  Multi-Library 
Environment  provides  a  powerful  way  of  managing  Ada  development  efforts.  It  allows 
compilation  units  to  be  flexibly  shared  among  libraries,  and  eliminates  the  need  to  copy 
library  units  to  share  them,  along  with  the  associated  version  control  problems. 

Although  it  has  the  features  mentioned  above,  we  decided  against  using  it, 
because  the  compilation  time  is  too  long  when  compared  to  the  other  languages. 

c.  3Vs  Parallel  C+-f  Programming  Language 

(1)  Abstract  Model  The  treatment  of  parallel  processing  in  transputer 
systems  is  based  on  the  idea  of  communicating  sequential  processes  which  is  explained  in 
part  B  of  this  chapter.  In  this  model,  a  computing  system  is  a  collection  of  concurrently 
active  sequential  processes  which  can  only  communicate  with  each  other  over  channels.  A 
channel  connects  exactly  one  process  to  exactly  one  other  process  and  can  only  carry 
messages  in  one  direction.  Each  process  can  have  any  number  of  input  and  output  channels, 
but  note  that  the  channels  in  a  system  are  fixed;  new  channels  cannot  be  created  during  its 
operation.  A  process  could  be  a  bit  of  hardware  or  a  software  module;  in  particular  it  may 
also  be  another  complex  system,  itself  consisting  of  a  number  of  communicating  processes. 

(2)  Hardware  Model  The  transputer  was  designed  to  be  used  as  a 
component  in  concurrent  systems.  Each  transputer  processor  has  four  Inmos  links,  to 
connect  it  with  other  transputers.  Each  link  has  two  channels,  one  in  each  direction.  These 
hardware  channels  provide  synchronized,  unidirectional  communication. 

Arbitrary  networks  of  transputers  can  be  constructed  simply  by 
connecting  their  links  together  with  ordinary  wires,  the  only  limitation  being  that  each 
processor  cannot  be  directly  connected  to  more  than  four  others.  A  transputer  can  therefore 
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be  viewed  as  a  single  process  in  a  multi^transputer  system.  However,  it  is  also  possible  for 
any  number  of  concurrent  processes  to  be  run  on  an  individual  transputer.  Any  word  in  the 
transputer’s  memory  may  be  used  as  a  channel  to  connect  one  internal  process  to  another. 
The  address  of  such  a  channel  word  is  used  to  identify  it  to  the  transputer  instructions  (and 
Parallel  C-h-  functions)  which  send  or  receive  messages.  The  contents  of  the  word  are  used 
by  the  hardware  to  synchronize  sending  and  receiving  processes. 

From  a  program’s  point  of  view,  these  internal  channels  and  the  hardware 
link  channels  are  identical.  The  same  instructions  (or  parallel  functions)  are  used  to 
send  and  receive  messages  on  both  internal  channels  and  the  hardware  link  channels. 
Hardware  link  channels  are  identified  by  special  fixed  addresses,  but  internal  channels  have 
addresses  allocated  by  software. 

The  equivalence  of  internal  channels  to  hardware  link  channels  means  it 
is  possible  to  develop  a  parallel  system  on  a  single  transputer  and  then  move  some  of  its 
processes  onto  other  transputers  without  having  to  recompile  any  code. 

(3)  Software  Model  Parallel  C++  is  based  on  the  same  abstract  model  of 
communicating  sequential  processes  as  the  transputer  hardware. 

A  complete  application  is  viewed  as  a  collection  of  one  or  more 
concurrently  executing  tasks.  Each  task  has  its  own  region  of  memory  for  code  and  data,  a 
vector  of  input  ports,  and  a  vector  of  output  ports.  The  port  vectors  are  passed  to  the  task 
as  arguments  to  its  main  function,  llie  code  of  a  task  is  a  single  transputer  image  {.b4)  file 
generated  by  the  ordinary  linker,  linkl. 

Tasks  can  be  treated  as  atomic  building  blocks  for  parallel  systems,  to  be 
wired  together  rather  like  electronic  components.  Indeed,  several  such  basic  building-block 
tasks  are  supplied  with  the  compiler. 

Each  element  in  the  input  and  output  port  vectors  is  of  type  “pointer  to 
channel  word’’,  {*CHAN).  Ports  are  bound  to  real  channel  addresses  by  configuration 
software  external  to  the  task  itself;  the  bindings  can  be  changed  without  recompiling  or 
relinking  the  task.  Extended  C++  run-time  library  functions  supplied  with  the  compiler 


17 


allow  C-H-  programs  to  send  and  receive  messages  over  the  channels  bound  to  a  task’s 
ports. 

The  configuration  software  also  provides  ways  of  specifying  which 
software  tasks  are  to  be  run  on  which  hardware  processors.  Each  processor  can  support  any 
number  of  tasks,  limited  only  by  available  memory. 

Tasks  placed  on  the  sante  processor  can  have  any  number  of 
interconnecting  channels.  Tasks  placed  on  different  processors  can  only  be  connected 
where  physical  wires  connect  the  processors’  links.  Each  logical  connection  between  two 
tasks  placed  on  different  processors  is  assigned  exclusive  use  of  one  the  physical  link 
channels  connecting  the  processors.  The  number  of  interconnections  between  tasks  on 
different  processors  is  therefore  lintited  by  the  number  of  hardware  links  each  one  has. 

(4)  Parallel  Execution  Threads.  The  software  features  described  so  far 
allow  us  to  build  parallel  systems  by  connecting  together  the  ports  of  a  number  of  relatively 
independent  tasks.  In  particular,  all  the  tasks  have  separate  code  and  data,  and  are  only 
allowed  to  communicate  with  each  other  by  sending  messages  over  channels. 

All  of  the  code  of  a  task  can  be  written  in  an  ordinary  sequential  language, 
except  for  one  extra  feature  needed  by  languages  based  on  the  communicating  sequential 
processes  idea.  This  extra  feature  is  a  way  of  making  a  process  wait  until  a  message  is 
received  on  any  one  of  a  number  of  input  channels.  In  Parallel  C-m-,  it  is  catered  for  by  the 
ability  to  create  new  concurrent  threads  of  execution  within  a  task.  The  task  creates  one 
thread  for  each  input  channel.  Each  thread  executes  a  sequential  message  input  call  and 
handles  messages  received  on  that  channel.  Each  one  of  Parallel  C’s  threads  has  its  own 
stack  (allocated  by  its  creator),  but  shares  its  code,  and  all  of  its  static  and  heap  data,  with 
any  other  threads  in  the  same  task.  Semaphore  functions  in  the  run-time  library  are  used  to 
prevent  threads  to  interfering  with  each  other. 

(5)  Configuring  An  Application.  Once  an  application  has  been  designed 
and  written  as  a  collection  of  communicating  tasks,  it  is  loaded  into  physical  network  of 


transputers.  First,  each  individual  task  is  built  by  compiling  all  its  source  files  with  the  C4<«- 
compiler  and  using  the  linker  (Unkt)  to  combine  the  resulting  binary  {.bin)  files  with  the 
Parallel  C-f-f  run-time  library  to  produce  a  task  image  {.b4)  file.  Then,  a  bootable 
application  image  file  must  be  generated  from  the  component  task  (.M)  files.  The  program 
which  does  this  is  called  the  configurer.  It  is  driven  by  a  user-supplied  configuration  file 
which  specifies: 

*  the  hardware  configuration  (processors,  and  the  wires  connecting  them) 
on  which  the  application  is  to  be  run; 

*  the  names  of  the  .b4  files  containing  the  component  tasks  of  the 

application; 

*  the  connections  between  the  various  tasks’  ports; 

*  the  placement  of  particular  tasks  onto  particular  tasks  onio  puiucular 
processors  in  the  physical  network. 

The  output  of  the  configurer  is  an  application  file  which  can  booted  into 
the  specified  hardware  network  and  run  using  the  same  ctfserver  program  used  for  simple 
stand-alone  programs.  The  afserver  task  is  an  ordinary  MS-DOS  executable  {.exe)  file  that 
runs  on  the  PC.  It  loads  executable  .b4  files  into  the  transputer  and  also  acts  as  a  file  server, 
handling  I/O  requests  made  by  the  transputer.  The  afserver  the  transputer  execute  in 
parallel  and  communicate  via  an  IM>4CS  link.  The  messages  sent  to  the  afserver  are 
normally  generated  by  the  Parallel  C-h-  run-time  library.  It  converts  I/O  operations  into 
messages  requesting  the  afserver  to  perform  MS-DOS  operations  and  then  waits  for  the 
afserver  to  reply. 

(6)  Processor  Farms,  'fhe  tools  described  so  far  allow  you  to  build 
applications  which  execute  on  any  transputer  network  the  wiring  of  which  can  be  specified 
in  advance  in  a  configuration  file.  For  many  parallel  computations  it  is  useful  to  be  able  to 
create  applications  which  will  automatically  configure  themselves  to  run  on  any  network 
of  transputers.  Such  applications  will  automatically  run  faster  when  more  transputers  are 
added  to  a  network,  without  recompilation  or  reconfiguration. 
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Pandlel  C^h-  allows  us  to  create  applications  like  this,  provided  the 
application  can  be  implemented  by  a  processor  farm,  and  provided  that  there  is  enough 
ntemory  on  each  processor  in  the  network  to  support  the  required  loading  and  message 
handling  software. 

The  processor  farm  is  a  method  of  building  applications  for  the  transputer. 
Many  users  have  found  it  a  useful  technique,  for  the  following  reasons: 

*  It  takes  full  advantage  of  the  transputer’s  parallel  processing  facilities 
and  the  ability  of  transputers  to  work  together  in  groups. 

*  Many  existing  sequential  programs  can  be  converted  into  processor 
farms  without  much  difficulty. 

**  A  processor  farm  is  not  restricted  to  a  particular  network  of  transputers, 
but  will  automatically  take  advantage  of  the  processors  it  fmds. 

A  processor  farm  includes  two  independent  programs,  or  tasks,  written  by 
the  user.  These  are  called  the  master  task  and  the  worker  task.  There  is  only  one  copy  of  the 
master  task,  and  this  is  placed  on  the  root  transputer,  that  is,  the  transputer  which  is  directly 
connected  to  the  host  A  copy  of  the  worker  task  is  placed  on  every  transputer  in  the 
network. 

The  function  of  the  master  task  is  to  break  up  the  job  which  is  to  be  done 
into  a  number  of  small,  independent  sub-jobs,  each  of  which  is  performed  by  one  of  the 
copies  of  the  worker  task.  The  master  does  this  by  sending  details  of  the  sub-job  to  be  done 
to  the  worker  task.  The  worker  task  sends  the  results  of  its  work  back  to  the  master  task, 
which  combines  it  with  the  results  from  all  the  other  worker  tasks.  The  v/orker  task  is 
written  in  such  a  way  that  immediately  after  sending  its  results  back  to  the  master,  it  is  ready 
to  receive  details  of  another  sub-job,  and  so  on. 

The  communication  between  the  master  and  the  workers  can  be  in  two 
ways.  Either  another  task  called  router  can  be  written  by  the  user,  or  special  procedures 
which  are  included  in  the  mn-time  libraries  of  the  parallel  languages  and  automatically 
added  to  the  processor  farm  can  be  used. 
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m.  DETAILED  PROBLEM  STATEMENT 


A.  PEGASUS  DATABASE 

1.  Introduction 

The  PEGASUS  Perspective  View  Database  (PVDB)  [Ref.  14]  is  a  geographic 
database  containing  elevation  data,  gray  shades  taken  from  aerial  photographs,  vegetation 
heights,  and  other  information  required  for  perspective  view  generation.  The  PVDB  comes 
in  four  resolutions:  1-,  4-,  16*and  64-metcr. 

The  Fort  Hunter-Liggett  (FHL)  PVDB  covers  a  rectangular  area  on  the  ground 
measuring  32x28  kilometers.  Its  southwest  comer  is  at  UTM  coordinates  43328,63904  and 
its  northeast  comer  is  at  UTM  76095,92575.  The  latitude  and  longitude  of  these  two  points 
are  ^>proximately  35*  48'N,  121*  25' W  and  36*  4'  N,  121*  4'W, 

2.  Database  Organization 

The  PVDB  is  organized  as  a  collection  of  tiles,  blocks,  and  posts  (see  Figure  3.1, 
Figure  3.2  and  Figure  3.3).  A  post  is  the  smallest  element  in  the  database  and  covers  an  area 
on  the  ground  measuring  1x1, 4x4, 16x16,  or  64x64  meters  for  the  1-,  4*,  16-,  and  64-meter 
databases  respectively.  A  post  is  the  only  database  element  for  which  the  area  of  coverage 
is  resolution  dependent 

A  block  is  a  collection  of  posts  that  always  covers  an  area  on  the  ground 
measuring  256x256  meters,  but  the  number  of  posts  in  a  block  depends  on  the  resolution. 
A  block  in  the  1 -meter  PVDB  contains  256x256  posts,  a  4-meter  block  is  made  up  of  64x64 
posts,  a  16-meter  block  contains  16x16  posts  and  a  64-meter  block  has  4x4  posts. 

A  tile,  the  largest  element  in  the  database,  is  a  collection  of  blocks  which  always 
covers  an  area  on  the  ground  measuring  4096x4096  meters.  A  tile  contains  a  16x16 
arrangement  of  blocks  regardless  of  resolution. 
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PVDB  DATABASE 


UTM  NORTHING 


Figure  3.1:  Pegasus  Perspective  Database 
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PVDB  EASTING 


Figure  3.2:  PVDB  Tile  Structure 
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Figure  3.3:  PVDB  Block  Structure 
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As  shown  in  Hgure  3. 1 ,  The  Fort  Hunter-Liggett  (FHL)  covers  a  rectangular  area 
which  consists  of  56  tiles  totally.  The  terrain  data  for  25  of  them  (white  area  in  Figure  3.1) 
forms  the  actual  database.  Specifically,  it  covers  400  km^  area  of  FHL.  This  area  is  used  for 
training  purposes. 

Now,  we  can  summarize  the  size  information  of  a  die,  a  block  and  a  post  for  4 
different  resolutions  as  follows: 


RESOLUTION 

POST  SIZE 

BLOCK  SIZE 

TILE  SIZE 

1  meter 

32  bits 

256  Kbytes 

64  Mbytes 

4  meter 

32  bits 

16  Kbytes 

4  Mbytes 

16  meter 

32  bits 

1  Kbyte 

256  Kbytes 

64  meter 

32  bits 

64  Bytes 

16  Kbytes 

3.  Post  Structure 

Figure  3.4  shows  how  each  post  in  the  PVDB  is  packed  and  how  the  32  bits  arc 
distributed  among  the  elements: 
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Figure  3.4:  PVDB  Post  Structure 


The  element  infonnation  is  as  follows: 


ELEMENT 

CODE 

NUMBER 

OF  BITS 

MAXIMUM 

VALUE 

DESCRIPTION 

ELE 

11 

2047 

Elevation,  in  meters 

EL2 

12 

4095 

Elevation,  in  half-meters 

ua 

2 

3 

Under  Cover  Inaex 

NOR 

4 

15 

Surface  Normal  Indicator 

VGH 

4 

15 

Vegetation  Height  Index 

VID 

2 

3 

Vegetation  ID 

NAT 

1 

1 

Nature 

SSB 

1 

1 

Sun  Shade  Bit 

GSV 

6 

63 

Gray  Shade  Value 

Each  element  has  the  following  meanings  (sec  Figure  3.5): 


ELE:  The  bald  terrain  elevation  plus  the  vegetation  height  (in  meters)  above  the 
lowest  point  in  the  database.  At  FHL  the  lowest  point  is  sea  level. 


EL2:  Same  as  ELE  except  the  units  are  in  half-meters. 


UCI:  The  height,  in  meters,  of  a  cultural  feature  above  the  ground  (tree  branches, 
caves  of  buildings,  etc.). 


NOR:  A  value  which  serves  as  an  indication  of  the  surface  normal. 


VGH:  Height  of  the  cultural  feature.  The  stored  values  of  0  to  IS  indicate 
vegetation  heights  of  0  (water),  0  (grass),  1,  2,  3,  4,  5,  8, 10,  15,  20,  25,  30,  35, 40,  and  47 
meters. 
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VID;  Indicates  the  cultural  feature.  This  value  is  combined  with  UCl,  NOR, 
VGH,  and  NAT  to  determine  what  a  particular  object  is. 

NAT:  If  set  to  1,  this  value  indicates  the  culnual  feature  is  naniral,  otherwise  it  is 
man-made. 

SSB:  If  set  to  0,  this  post  is  shaded  by  another  cultural  feature.  This  value  is  time- 
dependent 

CSV;  A  linear  set  of  values  ranging  from  0  to  63,  where  0  indicates  black  and  63 

is  white. 

B.  LINE-OF-SIGHT  CALCULATION 

Line-of-sight  (LOS)  is  a  central  process  in  combat  simulations  that  works  at  item 
level  [Ref.  Ij.  The  LOS  algorithm  is  critical  to  the  processes  being  simulated  and  impacts 
the  run  speed  (ratio  of  gtme  time  to  real  time),  since  it  may  be  the  single  most 
computationally  expensive  algorithm  in  simulation.  Some  LOS  considerations  in  Janus 
have  been  simplified  to  increase  computational  efficiency. 

There  are  three  general  aspects  of  LOS  processing  [Ref.  1  :pp.  107- 1 10] ; 

1 .  LOS  in  support  of  detections. 

2.  LOS  through  smoke  and/or  dust  clouds. 

3.  LOS  supporting  force  deployment. 

For  this  thesis,  we  implemented  the  LOS  calculation  for  the  first  aspect  which  is  LOS 
in  support  of  detections.  A  short  description  will  be  given  for  the  other  two  aspects. 

1.  Line-of-sight  for  Detect!  in 

The  first  d'^rrmination  to  be  made  is  whether  or  not  terrain  features  block  the 
LOS  between  the  observer  and  the  target  (see  Figure  3.6).  The  process  is  as  follows: 
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•  The  direct  line  between  the  observer  and  the  target  is  determined,  its  length 
calculated  and  it  is  divided  into  equidistant  points.  Each  point  is  tested  to 
determine  if  a  terrain  feature  affects  the  probability  of  LOS  (PLOS). 

•  The  number  and  the  location  of  points  on  the  line  are  determined  as  follows: 

•  Compute  the  distance  between  the  observer  and  the  target  (delta(X)  and 
delta(Y)). 

-  Determine  N(X)  and  N(Y)  by  dividing  delta(X)  and  delta(Y), 
respectively  by  the  terrain  grid  size.  Assign  the  larger  of  N(X)  or  N(Y) 
to  Np,  which  is  the  number  of  points  to  be  tested  along  the  LOS  line. 

-  Compute  dX  *  delta(X)  /  Np  and  Dy  =  delta(Y)  /  Np. 

-  Start  at  the  observer’s  position  +  (dx.dy)  and  determine  the  terrain  height 
(ground  slevadon)  of  the  grid  in  which  that  point  rests.  If  the  ground  elevation 
is  greater  than  that  of  the  observer,  LOS  is  blocked  and  the  process  is  completed 
for  that  observer-target  pair. 

•  If  tlie  tenain  height  at  that  point  is  less  than  or  equal  to  the  height  of  the  observer, 
add  the  height  of  treesAirban  areas  in  that  grid  and  recompute  the  terrain  height 
If  the  ground  elevation  -f  features  height  is  greater  than  that  of  the  observer, 
PLOS  is  decremented  by  the  LOS  degradation  factor  caused  by  features  in  the 
grid. 

-  If  tlie  resulting  PLOS  is  greater  than  0.0 1 ,  dx  and  dy  are  added  to  the  old  position 
and  the  process  continues  until  LOS  is  considered  blocked  or  the  target  position 
is  reached.  A  random  number  is  drawn  and  compared  with  the  resultant  PLOS 
to  determine  if  acquisition  has  taken  place. 

2.  LOS  Through  Smoke/Diist  Clouds 

If  LOS  exists  between  the  target  and  the  observer,  the  model  checks  to  see  if  any 
smoke  or  dust  blocks  the  LOS  line. 
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3.  LOS  For  Deployment 

The  LOS  for  any  unit  can  be  displayed  by  the  gamer  from  the  workstation  by 
pucking  the  LOS  block  on  the  menu  and  then  the  unit  The  parameters  of  the  LOS  fan  are 
attached  to  each  unit  depending  on  its  sensor  Gteight,  range)  and  how  the  orientation  and 
width  of  the  fan  have  been  previously  set  by  the  gamer. 

C.  WHY  1-METER  RESOLUTION? 

To  have  reliable  data  that  represents  a  terrain,  there  are  some  concepts  that  should  be 
considered.  First  we  will  describe  these  concepts  with  the  help  of  Figure  3.5  and  Figure 
3.7. 


Figure  3.7:  General  View  of  A  Terrain 
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The  calculation  of  LOS  is  based  on  data  stored  in  a  grid  of  square  cells.  The  elevation, 
the  height  of  trees  or  urban  buildings  are  stored  as  part  of  the  terrain  database  and  they  are 
the  factors  which  cause  the  unevenness  of  the  terrain. 

In  Figure  3.7,  D  represents  the  length  of  one  sid  of  square  cells.  AXy  and  AX2 
represent  the  “absolute  variation"  which  shows  the  unevenness  of  the  terrain.  Hy  and  H2 
represent  the  height  values  to  be  assigned  to  those  square  cells. 

The  real  height  values  are  mostly  expected  to  have  some  decimal  digits.  So,  these 
values  should  be  rounded  by  using  a  resolution  value  before  being  assigned  to  tlie  square 
cells.  We  call  this  resolution  value  as  "height  resolution”  and  symbolize  it  as  "aH". 

The  question  at  this  moment  is  how  we  can  choose  the  best  aH.  To  answer  this 
question,  first  we  consider  a  flat  terrain  (see  left  cell  in  Figure  3.7)which  means  that  aX  is 
small.  In  this  case,  a  small  A  H  can  be  reasonable.  But,  when  a  rough  terrain  which  has  a 
big  aX  is  considered  (see  right  cell  in  Figure  3.7),  a  small  AH  >vill  not  work  well.  For 
example,  assume  we  are  using  10  centimeter  height  resolution  when  dealing  with  a  terrain 
which  has  10  meter  of  absolute  variation.  Using  such  a  small  height  resolution  i.e. 
sensitivity  for  an  absolute  variation  which  is  relatively  too  high  for  that  height  resolution 
value  will  not  give  reliable  rounded  numbers  for  the  real  height  values  for  the  square  cells. 
So,  our  first  conclusion  is  as  follows: 

Conclusion  1:  The  best  idea  is  to  equalize  AH  and  AX  or,  to  choose  aH  which 
is  bigger  than  A  X. 

Before  applying  the  fust  conclusion  to  our  problem,  we  should  fust  normalize 
absolute  variation  and  height  resolution.  Eq  3.1  and  Eq  3.2  show  this  process: 

Normatlzed  Terrain  Variation  ■  ^  (Eq  3.1) 

Non.iaiised  Height  Resolution  ■  ~  (Eq  3.2) 


32 


After  normalizing  process,  we  can  approach  to  our  problem  more  specifically  as 
follows: 

We  assume  the  reasonable  normalized  terrain  variation  for  a  man-made  flat  surface 
as  about  0.5%,  for  a  natural  terrain  as  about  5%  and  for  a  rough  terrain  as  about  50%. 

Since,  The  Fort  Hunter-Liggett  training  area  can  be  accepted  as  a  rough  terrain,  then 
our  second  conclusion  is  as  follows: 

Conclusion!:  The  normalized  height  resolution  to  be  chosen  should  be  around 

50%. 

Another  important  factor  for  our  problem  is  the  length  of  one  side  of  a  square  cell, 
namely  D.  It  is  obvious  that  when  D  increases,  AX  will  increase  with  a  high  probability 
since  more  elevation  differences,  more  trees  or  more  urban  buildings  will  be  inside  the 
borders  of  one  square  cell.  We  believe  that  this  situation  should  be  avoided  to  have  reliable 
height  values  for  each  cell.  Because,  we  will  use  a  constant  height  resolution  value  and  a 
constant  D  for  our  all  database  and  we  should  not  increase  the  probability  of  having  big 
values  of  A X  by  increasing  D.  So,  our  third  conclusion  is  as  follows: 

Conclusion  3:  For  rough  terrain  databases  the  D  value  should  be  as  sntall  as  it 

can. 

When  we  considered  all  of  the  concepts,  factors  and  conclusions,  we  see  that  1 -meter 
resolution  database  with  a  50  centimeter  height  resolution  which  has  a  50%  normalized 
height  resolution  is  best  to  apply  to  our  problem,  and  we  believe  that  it  represents  The  Fort 
Hunter-Liggett  terrain  very  reliably. 
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IV.  TRANSPUTER  IMPLEMENTATION  OF  LINE-OF-SIGHT 

CALCULATION 


A.  HARDWARE 

1.  General 

The  designed  network  of  transputer  implementation  of  LOS  calculation  consist  of 
following  elements: 

-  An  IBM  PC  as  a  host 

•  An  IMS  B004  Evaluation  Board  inside  IBM  PC 

-  An  ALTA  Remote  TRAM  Holder 

-  An  ALTA  CrRAM-25-4F  (with  1  T805  25  MHz  transputer) 

-  A  SUN  SPARC  Station 

-  An  ALTA  HSI/SBus  inside  SUN  SPARC  Station 

•  An  IMS  B012  Evaluation  Board 

-  16  ALTA  CTRAM-25-4F  (with  16  TSOO  20  MHz  transputers) 

A  general  view  of  the  network  is  shown  in  Figure  4.1.  In  section  2,  each  of  the 
network  elements  will  be  mentioned  in  detail.  In  section  3,  the  implementation  will  be 
described  with  the  modifications  made  by  us  towards  our  design  purposes. 

2.  Background 

a.  The  Transputer/ Host  Relationship 

The  transputer  is  normally  employed  as  an  addition  to  an  existing  computer, 
referred  to  as  the  host.  Through  the  host,  the  transputer  application  can  receive  the  services 
of  a  file  store,  a  screen,  and  a  keyboard  as  shown  in  Figure  4.2. 

When  the  host  is  equipped  with  an  add-in  transputer  interface  board  and  the 
appropriate  software,  we  call  it  a  transputer  development  system.  Presently,  the  host 
computer  can  be  an  IBM  PC  or  compatible,  a  NEC  PC,  a  DEC  MicroVAX  II,  or  a  Sun 
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SPARC  Station  in  transputer  development  systems.  But  with  the  current  capacity  of  our 
laboratory  we  are  able  to  use  an  IBM  PC  for  our  implementation. 


Figure  4.2:  The  IVansputer/Host  Relationship 
b.  IBM  PC  As  A  Host 

The  transputer  communicates  with  the  host  along  a  single  INMOS  link.  A 
program  called  a  server  [Ref.  IS],  executes  on  the  host  at  the  same  time  as  the  program  on 
the  transputer  network  runs.  The  server  ensures  that  the  access  requirements  of  the 
application  in  terms  of  keyboard,  screen,  and  filing  are  fully  satisfied.  All  communications 
between  the  application  running  on  the  transputer  and  the  host  services  (like  screen, 
keyboard,  and  filling  resources)  take  the  form  of  messages.  The  standard  transputer  C,  C-h-, 
Pascal,  and  Fortran  development  systems  uses  a  server  called  afserver.  The  Occam  toolset 
uses  a  server  called  iserver. 

The  root  transputer  in  a  network  is  the  transputer  connecting  to  the  host  bus 
via  a  link  adapter.  Any  other  transputers  in  the  network  are  connected  together  using 
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INMOS  links,  to  the  root  transputer.  A  transputer  network  can  contain  any  size  and  mix  of 
transputer  types. 

Transputer  components  form  a  unique  hardware  environment  which  is  not 
immediately  compatible  with  most  existing  personal  computers  (PC)  or  main  frames  upon 
which  development  work  is  accomplished.  The  IMS  B004  evaluation  board  was  designed 
to  meet  these  needs  by  interfacing  a  transputer  memory  with  an  IBM  type  PC  allowing  the 
software  developer  to  edit,  compile  and  test  software  using  the  PC  as  a  host 

c.  The  IMS  B004  Evaluation  Board 

The  IMS  B004  board  is  logically  divided  into  three  distinct  parts  [Ref.  16]: 

1 .  The  transputer,  with  buffered  links  and  one  or  two  megabytes  of  RAM. 

2.  The  PC  subsystem  logic,  which  allows  a  program  running  on  the 
Personal  Computer  to  reset  and  analyze  systems. 

3.  The  IMS  C002  link  adaptor,  which  interface  to  a  parallel  address/data 
bus,  such  as  the  one  provided  on  the  system  expansion  slots  within  an 
IBM  PC.  The  link  adaptor  is  accessed  by  a  program  running  on  the 
Personal  Computer  to  transfer  data  to  and  from  the  transputer.  This 
device  can  convert  PC’s  byte-wide  parallel  data  into  serial  link  data  for 
the  transputer  links,  and  visa  versa. 

These  three  distinct  parts  of  the  board  are  joined  together  by  jumpers.  The 
“Reset”  jumper  allows  the  PC  subsystem  to  respond  to  addresses  from  the  PC,  and  connects 
the  transputer’s  reset,  analyze,  and  error  signals  to  those  controlled  by  the  PC.  The  “Link” 
jumper  connects  the  link  adaptor  to  one  of  the  transputer’s  links,  and  allows  the  Liidc 
Adaptor  to  respond  to  addresses  from  the  PC.  Figure  4.3  shows  a  block  diagram  of  the  B(X)4 
board  which  fits  in  a  full  length  eight  bit  slot  of  an  IBM  PC  [Ref.  17]. 

Before  any  program  can  be  downloaded  to  a  B004  board  from  a  PC,  two 
jumper  sockets  must  be  fitted  correctly.  The  use  of  these  jumpers  allows  more  than  one 
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B004  to  be  present  within  a  PC,  but  allowing  only  one  of  them  to  respond  to  the  Transputer 
Development  System  (TDS). 


The  board  which  has  the  jumpers  fitted  is  designated  the  Master,  and  any 
number  of  other  INMOS  evaluation  boards  can  be  attached  to  this  one  via  the  links.  Figure 
4.4  shows  the  rear  edge  connectors  of  the  B004,  looking  from  the  rear  of  :he  board.  As  can 
be  seen,  there  are  two  columns  of  pins,  and  these  are  grouped  into  sets  of  five,  suitable  for 
the  five  way  sockets  which  terminate  the  various  cables  supplied. 

The  link  sockets  arc  self  explanatory.  The  Up,  Down  and  Subsystem  sockets 
arc  concerned  with  system  control,  initialization  and  error  handling.  The  simplest  way  to 
use  them  is  to  connect  the  DOWN  socket  of  the  Master  TDS  board  to  the  Up  socket  of  the 


38 


next  board  with  the  Reset  cable,  and  then  daisy  chain  the  Down  from  each  board  to  the  Up 
of  the  next.  This  nwthod  ensures  that  when  the  TDS  resets  the  first  board,  all  others  in  the 
chain  are  also  reset  (see  Figure  4.5). 


Figure  4.5:  Daisy  Chaning  of  the  Subsequent  Boards 
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The  3004  board  uses  a  group  of  5  way  connectors,  to  simplify  the  location  of 
the  various  leads  for  a  system  (see  Figure  4.6). 
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Figure  4.6:  The  B004  Board  Edge  Connector  Pinout 


The  NotLink  (b6)  and  NotSystem  (b27)  are  used  in  conjunction  with  the  Link 
and  Reset  jumpers  described  previously.  When  these  signals  are  at  logic  0,  they  select  the 
function  associated  with  either  reset  or  link  to  respond  to  signals  from  the  PC. 

d.  ALTA  CTRAM  (Computation  TRAnsputer  Module) 

The  ComputeTRAM  (or  CTRAM)  [Ref.  18]  consists  of  a  circuit  board  with 
transputer,  memory,  and  connective  hardware  which  is  plugged  into  a  TRAM  Holder  from 
ALTATechnology  or  similar  boards  from  INMOS.  The  CTRAM  includes  from  1  to  32 
Mbytes  of  DRAM  and  supports  the  IMS  TSOx  transputer  (with  a  chip  floating  point 
processor)  or  IMS  T425  (integer  only)  transputers.  A  variety  of  processor  speeds  and 
memory  speeds  are  available,  providing  users  with  a  wide  range  of  cost-effective  compute 
modules. 

The  CTRAM  is  the  basic  urut  for  computation  in  parallel  processing 
applications.  With  its  range  of  external  memory  configurations  and  processor  speeds,  the 
CTRAM  is  a  versatile  tool  for  the  system  designer  or  the  system  integrator.  The  end-user 
can  fmd  extra  value  from  the  CTRAM  by  matching  the  configuration  of  each  CTTRAM  with 
the  needs  of  his  application.  This  customization  results  in  a  tailored,  economical  mix  of 
processors  and  memory  configurations. 

CTRAMs  may  be  connected  to  other  transputer  modules  via  its  four 
transputer  links  to  form  a  'vide  variety  of  topologies. 

The  module  pinouts  and  descriptions  for  CTTRAM  is  shown  in  Table  4.1. 

e.  ALTA  Remote  Tram  Holder 

The  Remote  TRAM  Holder  [Ref.  19]  may  be  mounted  inside  of  a  disk 
enclosure,  or  in  a  chassis  suitable  for  holding  disk  drives  and/or  transputer  modules.  Figure 
4.7  shows  the  block  diagram  of  an  ALTA  Remote  Tram  Holder. 
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TABLE  4.1:  CTRAM  MODULE  PINOUTS  AND  DESCRIPTIONS 


Q 

Pin  Name 

In/ 

Out 

Function 

1 

Link2o;it 

Out 

Link  2  output 

2 

Link2in 

In 

Link  2  input 

3 

VCC 

Power  (+5V) 

n 

Linklout 

Out 

Link  1  output 

5 

Linklin 

In 

Link  1  input 

6 

LinkSpeedA 

In 

Transputer  link  speed  selection  A 

a 

LinkSpeedB 

In 

Transputer  link  speed  selection  B 

8 

Clocldn 

In 

SMHz  clock  signal 

9 

Analyze 

In 

Transputer  analyze 

10 

Reset 

In 

lYansputer  reset 

11 

notEiror 

Out 

Transputer  error  indicator  (inverted) 

12 

LinkOout 

Out 

Link  0  output 

13 

LinkOin 

In 

Link  0  input 

14 

GND 

Ground 

15 

Link3out 

Out 

Link  3  output 

16 

Link3in 

In 

Link  3  input 
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(1)  Jumper  Options.  The  jumpers  in  location  P8  are  provided  to  allow  a  high 
degree  of  configuration  connects  Link  0  of  Module  0  with  external  link  0.  The  pins  are 
labeled  as  to  module  and  the  link,  and  contain  an  arrow  pointing  out  of  the  LINKOUT 
signal  towards  the  LINKIN  signal.  The  user  may  insert  jumpers  to  connect  any  external 
links. 

Jumper  J1  is  factory-set  to  20  Megabits/Second.  The  link  speed  can  be 
changed  to  10  Megabits/Second  as  a  second  alternative. 

(2)  External  Links.  The  differentially-driven  links  on  the  module  are 
com  rted  via  modular  plugs  and  jacks.  The  modular  connectors  found  at  locations  PI ,  P2, 
P3,  and  P4  correspond  with  XO,  XI,  X2,  and  X3  of  the  configuration  area  (P8).  Those  links 
can  be  connected  to  any  available  links  in  the  TRAM  SLOTs  by  jumpers  or  configuratioh 
modules. 

(3)  TRAM  SLOTs  and  Topology.  There  are  four  TRAM  SLOTs  on  the 
motherboard,  labeled  SLOTO  to  SLOT3.  They  are  an  anged  such  that  only  a  single  pair  of 
links  (between  SLOTl  and  SLOT2)  is  committed  (hardwired).  All  other  lirtks  arc  brought 
out  to  the  P8  configuration  area. 

(4)  System  Services.  The  Remote  TRAM  may  be  used  without  connecting 
system  services  (Enor,  Reset,  and  Analyze)  to  the  host.  The  board  will  assert  RESET  upon 
power  on.  However,  in  some  instances,  the  user  may  wish  to  access  system  services  from 
the  host.  Connector  P5  contains  the  equivalent  of  UP  system  services  and  should  be 
connected  to  the  host  Connector  P6  contains  the  equivalent  of  DOWN  services  and  should 
be  connected  towards  the  next  module  in  the  chain.  The  Error,  Reset,  and  Analyze  signals 
will  be  propagated  UP  and  DOWN  (depending  upon  the  signal)  properly  to  allow  daisy- 
chaining  of  the  system  services. 
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The  signals  on  P5  and  P6  are  as  follows: 

PIN  SIGNAL 

\  GROUND 

2  ERROR 

3  RESET 

4  ANALAYZE 

/.  HSl/SBus 

The  HSI/SBus  [Ref.  20]  is  a  single-slot  SBus  interface  between  the  Sun 
SPARC  Station  and  transputers.  It  provides  a  high-speed  interface  between  the  SBus  found 
on  a  Sun  SPARC  Station  and  Transputers. 

The  HSI/SBus  is  a  32-bit  SBus  slave  interface  for  a  Sun  SPARC  Station.  The 
HSI  provides  system  services  and  four  bidirectional  transputer  links  to  external  transputers, 
using  modular  connectors  and  twisted-pair  telephone  cables.  The  links  are  differentially 
driven  using  AT&T  41L/R  series  of  drivers.  The  HSI/SBus  board  is  a  single  slot  printed 
circuit  board  which  conforms  to  Sun  Microsystem’s  published  standards  for  a  single  slot 
SBus  card.  Figure  4.8  shows  the  layout  of  the  board  and  the  locations  of  the  major  board 
components. 


Figure  4.8:  The  HSI/SBus  Board  Layout 
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The  SBus  interface  provides  an  electrical  connection  between  the  host  and 
external  transputer  modules.  It  provides  four,  bi-directional  transputer  links  to  external 
transputers,  and  provides  a  set  of  control  signals  (Reset,  Analyze,  and  Error)  which  are 
controlled  by  the  driver  on  the  SPARC  Station  host 

When  the  interface  is  initialized,  transputer  boot  code  is  loaded  into  the  dual- 
ported  RAM  and  the  transputer  is  then  booted  from  that  RAM.  The  transputer  then  executes 
the  boot  code  to  perform  the  interface  functions. 

Connections  to  external  devices  are  made  by  using  modular  telephone  handset 
jacks.  Figure  4.9  shows  the  six  jacks  on  the  end  of  the  HSI-card. 


Facing  the  back  of  the  SPARC  Station 


¥  ¥  ¥  P  ¥  V 


LINKO  LlNKl  L1NK2  LINK3  DOWN  UP 

Figure  4.9:  HSI-Card  Link  and  Control  Connections 
The  four  links  from  the  host  interface  are  designated  LinkO,  Linkl,  Link2,  and 

Links. 

Reset,  Analyze,  and  Error  signals  are  provided  for  both  DOWN  and  UP 
connections.  The  DOWN  connector  sends  the  Reset  and  Analyze  signals  to  remote 
transputers. 

g.  The  IMS  B012  Evaluation  Board 

The  IMS  BO  12  [Ref.  21]  i.*;  a  eurocard  TRAM  motherboard  which  is  a  member 
of  a  family  of  TRAM  motherboards  which  have  a  compatible  architecture.  External  signals 
enable  it  to  control  a  subsystem  of  motherboards,  or  to  be  a  component  of  such  a  subsystem. 
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The  smallest  TRAM  is  “size  1”.  Each  of  the  16  sites  for  modules  on  the  IMS 
BO  12  board  accepts  a  size  1  module.  Each  module  site,  or  “slot”  has  connections  for  four 
INMOS  links  which  are  designated  link  0,  link  1,  link2,  and  link  3.  TRAMs  which  are 
larger  than  size  1  can  be  mounted  on  the  BO  12.  A  larger  module  occupies  more  than  one 
slot  and  need  not  use  all  of  the  available  link  connections  provided  by  the  slots  which  it 
occupies. 

The  BO  12  has  two  IMS  CXK)4  link  switches.  These  devices  are  able  to  connect 
together  links  from  the  slots  and  32  links  which  are  available  on  an  edge  connector.  The 
connections  can  be  changed  by  control  data  passed  to  the  board  down  a  configuration  link, 
which  may  come  from  some  master  system  or  from  one  of  the  TRAMs  on  the  BO  12  itself. 

The  B012  has  two  DIN41612  96-way  edge  connectors,  PI  and  P2.  These 
cany  almost  all  signals  and  power  to/from  the  board  and  are  easily  identified  from  the 
board  silk  screen  printing  and  from  Figure  4.10.  P2  carries  power,  pipeline  and 
configuration  links  and  system  control  signals  (reset,  analyze,  and  error). 


ngure  4.10:  IMS  B012  Slot  Positions 
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The  link  connections  to  the  16  slots  are  organized  as  follows: 

Two  links  from  each  slot  (links  1  and  2)  are  used  to  connect  the  16  slots  as  a 
16-stage  pipeline  (in  a  pipeline,  multiple  processors  are  connected  end-to-end  as  in  Figure 
4. 1 1).  The  pipeline  is  actually  broken  by  jumper  block  Kl.  K1  will  usually  be  jumpered  in 
the  standard  way  to  give  a  16-stage  pipeline  but  can  allow  other  combinations.  Figure  4.12 
shows  the  standard  jumper  configuration  for  Kl  which  connects  all  16  TRAMs  in  a 
pipeline. 


Figure  4.12:  Kl  Standard  Configuration 


Link  1  on  slot  0  is  wired  to  an  edge  connector  (P2)  and  is  called  PipeHead. 
Link  2  on  slot  IS  is  also  taken  to  P2  and  is  called  PipeTail.  By  connecting  the  pipe  heads 
and  tails  from  multiple  boards  together,  a  large,  multi-board  pipeline  is  created. 

The  other  two  links  (links  2  and  3)  of  each  slot  are,  in  general,  connected  to 
two  IMS  €004  programmable  link  switches.  The  IMS  CXXM  has  32  input  pins  and  32  output 
pins,  plus  an  INMOS  link  (ConfigLink)  used  to  send  configuration  infonnation  to  the  IMS 
CXX)4.  Any  of  the  output  pins  can  be  “connected”  to  any  of  the  input  pins,  so  a  signal 
presented  on  the  input  pin  would  be  buffered  and  transmitted  on  the  output  pin  (with  a  slight 
delay).  The  switch  connections  arc  made  according  to  information  sent  to  the  IMS  CX)04 
down  its  ConfigLink.  The  two  IMS  C(X)4s  on  the  IMS  BO  12  allow  64  link  connections  to 
be  made  under  software  control. 

The  Reset,  Analyze  and  Error  pins  of  TRAMs  (and  transputers)  is  generally 
referred  to  collectively  as  “system  services”.  The  system  service  signals  arc  used  to  reset 
TRAMs  and  transputers,  to  place  transputers  in  an  analyze  state  (for  debugging)  and  to 
carry  the  fact  that  an  error  has  occurred  in  one  processor  in  an  array  back  to  some  host 
system  which  will  deal  with  the  error  condition. 

Some  TRAMs  and  most  evaluation  boards  are  capable  of  generating  the 
system  services  for  other  TRAMs  and  transputers.  This  is  called  a  subsystem  control 
capability.  The  IMS  BO  12  can  be  connected  to  another  board  with  subsystem  control  and 
also  accommodate  one  TRAM  with  subsystem  control.  Furthermore,  the  IMS  BO  12  can 
generate  subsystem  control  signals  for  other  boards.  The  system  service  signals  are 
organized  in  such  a  way  that,  another  boards  can  be  daisy-chained  by  using  Up  and  Down 
pins  on  P2.  The  logic  here  is  same  as  it  is  for  B(X)4  boards. 

The  IMS  BO  12  has  a  six- way  DIL  switch  (SWl)  located  between  PI  and  P2. 
Each  of  the  six  switches  make  up  SWl  controls  one  signal  on  the  board.  When  a  switch  is 
on,  the  signal  is  low  and  when  the  switch  is  off,  the  signal  is  high.  So,  the  board  link  speed 
can  be  set  to  either  10  Mbits/s  or  20  Mbits/s  with  these  switches. 
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(1)  PI  ConntetioHS,  Connector  PI  has  three  rows  of  32  pins.  All  the  pins  in 
row  “a"  are  connected  to  the  ground.  All  the  pins  in  row  ‘b”  are  link  inputs  and  all  the  pins 
in  row  *‘c”  are  link  outputs.  At  each  of  the  32  positions  along  PI,  the  three  pins  from  rows 
a,  b  and  c  carry  one  link.  These  signals  may  be  connected  to  devices  with  link  ports  in  any 
way  the  user  desires. 

llie  link  connections  on  connector  PI  are  intended  mainly  for 
communication  between  the  IMS  B012  and  other  boards  in  a  card  cage.  However,  it  is  also 
possible  to  use  these  PI  links  and  the  IMS  C004  link  switches  to  switch  link  connections 
for  an  external  system. 

(2)  P2  Connections.  If  the  IMS  BO  12  is  to  be  used  in  an  INMOS  ITEM  card 
cage,  the  ITEM  supplies  power  and  has  a  built-in  back-to-back  connector  which  allows  link 
and  reset  cables  to  be  connected  to  P2.  Figure  4.13  shows  the  back-to-back  connector  pins 
as  viewed  from  the  rear,  i.e.  looking  towards  the  pins.  The  boxes  represent  plugged-in 
cables.  A  good  5V  power  supply  must  be  connected  to  the  appropriate  pins  on  P2. 
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(3)  IMS  B012  as  a  Slave  to  a  Master  Controller,  In  a  standard  configuration 
where  the  IMS  BO  12  is  connected  to  a  master-control  system  such  as  an  IMS  B004, 
PipeHead  and  ConfigUp  links  would  be  connected  to  two  links  on  the  host  system,  with 
“Up”  system  control  port  connected  to  the  “Subsystem”  port  of  the  host  (sec  Figure  4. 14). 


Figure  4.14:  The  IMS  B012  Board  as  a  Slave 

(4)  IMS  B012  as  a  System  Master.  If  a  TRAM  with  “subsystem”  capability 
is  installed  in  slot  0  then  the  IMS  BO  12  can  act  in  a  stand-alone  or  master  role.  With  switch 
6  (on  six-way  OIL  switch)  off,  the  system  control  to  the  other  modules  on  the  board  and  the 
“Down”  system  control  pins  on  P2  are  driven  from  the  subsystem  pins  on  the  TR.\M  in  slot 
0. 


3.  Our  Implementation 

The  steps  for  our  implementation  can  be  summarized  as  follows: 

-  To  disable  T414  transputer  on  the  B004  board  inside  the  PC  host. 

-  To  set  up  a  remote  tram  holder  and  to  place  our  root  transputer  on  it. 

-  To  connect  Sun  SPARC  Station  which  has  an  HSl/SBus  to  the  remote  tram 

holder. 
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•  To  place  16  T80S  transputers  on  a  B012  board  and  to  connect  B012  board  to 
the  remote  tram  holder  and  B004. 

-  To  set  the  link  speed  as  10  Mbits/second. 

(1)  Disabling  the  T414  Transputer  on  the  B004  Board.  As  we  have  seen  in 
the  section  which  is  related  with  B004  board,  only  T414  transputer  can  be  used  as  root 
transput^  on  a  B004  board  and  we  can  have  a  total  of  2Mbytes  RAM.  But  for  our 
application,  with  a  purpose  of  having  more  memory  and  speed,  it  was  decided  to  use  a  T80S 
transputer  as  root  transputer  with  a  total  of  4Mbytes  RAM,  namely  an  ALTA  CTRAM-2S- 
4F.  So,  the  T414  transputer  on  the  board,  had  to  be  disabled. 

To  disable  the  T414  transputer  on  the  B004  board,  two  connections  were 
made  between  two  different  pin  pairs  on  the  edge  connector.  These  connections  are  shown 
in  Figure  4.15. 

(2)  Setting  Up  the  ALTA  Remote  Tram  Holder.  After  disabling  the  T414 
transputer,  an  ALTA  CTRAM-25  4F  which  is  actually  a  25Mhz  T805  transputer  and 
4Mbytes  DRAM,  was  placed  on  slot  0  of  the  remote  tram  holder.  So,  this  transputer  became 
the  root  transputer. 

Since  a  Sun  SPARC  Station,  a  B004  board  and  a  BO  12  board  connections 
were  planned  for  the  remote  tram  holder,  each  of  them  had  to  be  taken  care  of  separately 
because  of  the  different  requirements. 

The  HSI/SBus  converts  the  Sun  SPARC  Station's  parallel  data  signals  to 
serial  data  signals  for  the  transputer  links.  The  voltage  for  the  produced  signal  varies 
between  -15  and  +15  AC.  But,  transputers  require  5V  DC  voltage.  This  voltage  conversion 
for  the  signals  is  normally  done  by  the  converter  on  the  remote  tram  holder  if  the  jumpers 
are  used  in  the  P8  Configuration  Area.  So,  two  jumpers  were  used  in  the  P8  Configuration 
Area  for  the  link  between  Sun  SPARC  Station  and  remote  tram  holder  to  allow  the 
necessary  conversion  and  to  assign  Link  3  of  the  root  transputer  to  the  Sun  SPARC  Station 
(sec  Figure  4.16). 
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Figure  4.15:  The  B004  Board  Edge  Connector  Pinout  After  Modification 
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Figure  4.16:  Remote  IVam  Holder  P8  Configuration  Area  After 

Jumpering 

Because  the  PC’s  parallel  data  signals  are  convened  to  serial  data  signals 
for  the  transputer  links  by  the  C002  Link  Adaptor  on  the  B004  board,  we  didn’t  need  the 
conversion  which  was  done  for  the  Sun  SPARC  Station  signals.  Then,  the  other  3  links 
Link  0,  Link  1  and  Link  2  of  the  root  transputer  had  to  be  connected  to  the  PC  and  BO  12 
board  directly,  without  using  jumpers  in  the  P8  Configuration  Area.  But,  the  modular 
connectors  P1-P6  (P1-P4  fc-r  transputer  links,  P5  and  P6  for  system  services)  have 
originally  AT&T  4iL/R  series  of  drivers.  So,  those  three  links  and  UP  and  DOWN  system 
services  were  carried  to  a  connector  which  was  located  at  the  back  of  the  remote  tram 
holder  and  which  had  drivers  for  transputer  link  cables  and  for  system  service  cables.  For 
carrying  links,  two  wires  were  used,  one  lor  LinkOut  and  one  for  Linkln  signal  (see  Figure 
4. 16).  For  carrying  system  services,  tliree  wires  were  used,  one  for  Analyze,  one  for  Reset 
and  one  for  Error  signal.  Figure  4.17  shows  the  connections  made  inside  the  remote  train 
holder. 
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Link  0  Link  1  Link  2  Up  Down 


Figure  4.17:  The  Connections  Made  Inside  the  Remote  Ti  am  Holder 

After  the  connections  were  made  inside  the  remote  tram  holder,  the  16 
CTRAMs  were  placed  on  the  BO  12  board  and  16  T805-20  MHz  transputers  were  placed  on 
these  CTRAMs. 

The  fixed  hardware  configuration  for  all  the  transputers  m  the  ne.^ork  can 
be  checked  with  the  program  named  “check”.  This  program  runs  in  PC  Host.  Figure  4.18 
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shows  the  output  of  that  “check"  program  for  our  application^  and  Figure  4. 19  shows  the 
physical  view  of  our  current  fixed  hardware  configuration  that  we  have  for  our  transputers. 
We  will  see  how  a  parallel  application  is  created  for  a  multi-transputer  system  with  a  fixed 
hardware  configuration  in  the  software  part  of  this  chapter. 
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Figure  4.18:  The  Output  of ‘*Check"  Program  fur  Our  Application 


1.  For  example.  Figure  4.18  first  row  shows  the  following  connections  for  Transputer#  0  (root);  Its 
Link  0  to  Host,  its  Link  1  to  Link  1  of  Transputer#  1  and  its  Link  2  to  Link  2  of  Transputer#  2. 
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Figure  4.19:  The  Physical  View  of  the  Fixed  Hardware  Configuration 


And  finally  we  made  the  connections  for  Sun  SPARC  Station,  B004 
board,  BO  12  board  and  remote  tram  holder  as  shown  in  Figure  4.20  Figure  4.21  and  Figure 
4.22  (for  B(X)4,  refer  to  Figure  4.15). 

The  slot  0  link  0  on  the  B012  board  usually  needs  to  be  connected  to  IMS 
C004s.  This  standard  configuration  requires  a  connection  to  be  made  via  P2.  A  single 
connector  assembly  (termed  the  “yellow  link  jumper  plug")  are  used  for  this  purpose.  The 
position  of  the  jumper  is  shown  in  Figure  4.22. 


Facing  the  back  of  the  Sun  SPARC  Station 


LINKO  LINKl  LINK2  LINK3  DOWN  UP 


Telephone  Cable 


Facing  the  front  of  the  Remote  IVam  Holder 


LINKO  LINKl  LINK!  LINK3  DOWN  UP 


Figure  4.20:  The  Connection  Between  Sun  SPARC  Station  and  Remote 

Tram  Holder 
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(3)  Setting  Up  the  Link  Speed.  Because  of  the  B004  board’s  speed 
limitation,  we  set  up  the  link  speed  as  10  Mbits/sec.  To  set  up  link  speed  for  the  remote  tram 
holder,  we  connected  the  jun^r  J1  with  the  center  position  and  the  position  labelled  “10”. 
For  the  BO  12  board,  we  set  the  DIL  switches  for  links  to  operate  at  10  Mbits/sec. 

The  link  speed  set  up  for  the  Sun  SPARC  Station  is  made  by  running  an 
independent  program,  before  running  the  real  ^plication  program.  We  will  mention  about 
it  in  the  softwrje  section  of  this  chapter. 


Figure  4.21:  The  Connections  From  the  Back  of  Remote  TVam  Holder 
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Figure  4.22:  The  Connections  from  the  Back  of  B012  Board 
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B.  SOFTWARE 


1.  General 

The  elements  of  the  system  and  their  functionalities  from  the  software  side  of 
view  is  shown  in  Figure  4.23. 

The  main  processes  can  be  summarized  in  general  as  follows: 

'  The  link  operations  between  Sun  SPARC  Station  and  Remote  Tram  Holder  and 
setting  the  link  speed  as  10  Mbita/sec. 

-  Loading  the  height  data  of  the  selected  terrain  from  Pegasus  Database  to  the 
CTRAMs. 

•  LOS  calculation  between  the  start  and  goal  points  which  are  sent  to  Sun  SPARC 
Station  by  a  server  which  represents  JANUS. 

-  Sending  the  result  back  to  the  server  from  which  the  LOS  calculation  request  is 

nuide. 

•  The  afserver  task  on  PC. 

a.  Installing  HSIlBus  and  Setting  the  Link  Speed 

As  we  have  seen  in  the  hardware  part  of  this  chapter,  the  HSI/Bus  is  a  high¬ 
speed  interface  between  the  SBus  found  on  a  Sun  SPARC  Station  and  transputers  and  it 
provides  link  operations  between  them.  [Ref.20]  gives  ail  the  detailed  information  for 
installing  and  usage. 

The  program  which  sets  up  the  link  speed  between  Sun  SPARC  Station  and 
Remote  Tram  Holder  was  supplied  by  ALTA  Technology  Corporation  upon  the  request  of 
us.  The  link  speed  should  be  10  Mbits/sec  before  executing  the  main  program  because  of 
the  speed  limitation  of  the  PC  host. 
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Figure  4.23:  The  Elemmts  of  the  System  from  Software  Side  of  View 
b.  Our  Proeetsor  Farm  Application 

Three  things  must  be  written  to  create  a  processor  farm  application 
(Ref.  I2;p.  77): 

1.  A  master  task  to  split  up  the  job  into  the  independent  work  packets,  i.e.  sub¬ 
jobs. 

2.  A  worker  task,  which  is  automatically  copied  to  each  node  of  the  network 
of  transputers. 

3.  A  configuration  file,  describing  the  memory  requirements  and  other 
attributes  of  the  tasks. 
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(I)  Master,  Worker  and  Router  Tasks.  There  is  only  one  copy  oi  utc  nnuter 
task,  and  this  is  placed  on  the  root  transputer.  A  copy  of  the  worker  task  is  placed  on  every 
transput^  in  the  network. 

Special  procedures  are  included  in  the  run-tiine  libraries  of  the  Parallel 
languages  to  enable  the  communication  between  the  master  and  the  workers.  They  work  in 
conjunction  with  another  task,  called  the  router. 

Normally,  router  task  is  not  written  by  the  user,  but  is  automatically  added 
to  the  processor  farm.  When  the  ma.ster  has  a  sub-job  to  be  done,  it  calls  a  procedure  which 
gives  details  of  the  sub-job  to  the  router.  The  router  then  finds  a  woriter  somewhere  in  the 
network  which  is  currently  idle,  and  sends  the  work  packet  to  it  The  worker  task  then 
processes  the  work  packet  and  when  it  has  finished,  it  calls  a  procedure  to  send  the  result 
packet  back  to  the  router,  which  returns  it  to  the  master. 

For  a  normal  processor  farm  application: 

-  A  worko^  task  contains  three  sequences:  read  a  packet  process  it  send 
back  a  result  packet  (i.e.  input  process,  output). 

-  Every  worker  should  get  the  same  input 

-  For  every  cycle  those  three  sequences  start  from  the  beginning. 

But  for  our  application: 

-  Since  we  have  a  big  amount  of  map  data,  we  should  divide  it  to  little 
portions  and  load  them  to  different  CTRAMs  at  a  time.  Our  map  is  too  big  to  be  loaded  to 
a  CTRAM.  So  every  worker  has  different  input 

-  If  we  had  used  the  same  three  sequences  as  mentioned  above,  we  would 
have  to  load  the  whole  data  for  every  cycle.  This  would  be  too  time  consuming.  So,  we 
make  first  an  initialization  by  loading  the  map  data.  Then,  we  send  the  point  information  to 
workers  as  input  for  1X)S  calculation,  they  process  it  and  return  the  LOS  result  back.  And 
for  the  second  LOS  request  we  don’t  have  to  make  initialization  again.  Just  the  second  part 
that  includes  input,  process  and  output  sequences  repeats. 
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Because  of  the  differences  which  we  just  described,  routing  in  our 
application  is  done  with  the  programs  written  by  us  instead  of  being  done  automatically. 
The  source  files  for  master,  worker  and  router  tasks  are  listed  in  Appendix  B. 

(2)  Configuration  File.  The  configuration  file  [Ref.  12:p.  38]  lescribes  the 
system  to  be  built  It  lists  all  the  physical  processors  in  the  system,  the  wires  connecting 
them,  the  tasks  to  be  loaded  into  the  system  and  their  logical  interconnections.  In  this 
section  of  the  Chapter  IV  we  explained  configuration  file  giving  the  examples  from  our 
actual  configuration  file  "btestlSO.cfg”  which  is  listed  in  Appendix  B. 

The  first  thing  the  configuration  needs  to  describe  is  the  hardware 

configuration  between  the  processors.  The  following  configuration  file  lines  declares  the 

processor  in  the  host  PC,  the  processor  in  the  Sun  SPARC  station  and  diree  transputers 

including  the  root  transputer  and  describes  the  actual  physical  cables  between  these 

processors  for  our  application: 

processor  host 
processor  sun  type^pc 
processor  root 
processor  pi 
processor  pU 


wire  ? 

root[01 

host[0] 

wire  ? 

rootilj 

pl[ll 

wire  ? 

root[21 

p2[21 

wire  ? 

root[3] 

sun[0] 

wire  ? 

plI21 

pll[ll 

The  PROCESSOR  statement  declares  a  physical  processor.  Every 
processor  in  the  physical  network  must  be  declared,  including  the  host  processor  fi^om 

which  the  network  is  to  be  bootstrapped^  (normally  an  IBM  PC-type  machine).  The 
configurer  assumes  that  the  processor  named  host  is  the  host  processor.  In  the  case  of  an 


2.  The  linker  program,  linkt,  nomudly  produces  an  executable  image  G'.e  prefixed  by  a  short 
bootstrap  program  which  allows  the  the  afserver  to  load  the  image  into  an  empty  transputer  the 
bootstrap  initialises  the  transputer  and  reads  in  the  rest  of  the  image  file. 
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IBM  PC  host  processor,  the  host  will  usually  be  executing  the  afserver  program  when  the 
network  is  loaded,  simply  because  that  is  the  program  which  loads  the  rest  of  the  network. 
It  is  necessary  to  be  able  to  specify  the  afserver  task  to  the  configurer  so  that  its  ports  can 
be  connected  to  ports  in  user  tasks,  but  without  forcing  the  configurer  to  attempt  to 
bootstrap  the  IBM  PC.  Similarly,  some  processors  in  the  network  might  be  set  to  bc>otstrap 
from  ROM  rather  than  from  link.  A  processor  is  declared  to  the  confrgurer  as  having 
already  been  bootstrapped  by  means  of  the  '*type”  attribute.  The  default  for  the  host  is  that 
it  is  “type=pc”  already.  For  our  application,  the  Sun  SPARC  station  processor  was  also 
described  as  “type=pc”. 

The  WIRE  statement  declares  a  physical  wire  connecting  links  on  two 
physical  processors.  Each  wire  supports  two  connections,  one  in  either  direction.  The  two 
link  specifiers  in  the  WIRE  statement  may  therefore  be  interchanged  without  affecting  the 
statement’s  meaning.  Each  wire  is  given  a  name  (or  ‘7’  can  be  used  instead  of  a  name  if  the 
name  will  not  be  referred  later).  The  numbers  in  the  brackets  for  the  WIRE  statements  are 
the  link  numbers  of  those  processors  which  are  used  for  connection.  The  processor 
identifiers  used  in  a  wire  statement  must  have  been  declared  in  a  previous  PROCESSOR 
statement.  This  is  a  general  rule:  all  objects  in  the  configuration  language  (processors, 
wires,  tasks)  must  be  declared  before  they  are  used. 

As  well  as  describing  the  hardware  of  a  system,  the  configuration  file  must 
contain  details  of  all  its  software  tasks  and  their  interconnections.  For  each  concurrently 
executing  task  in  the  system,  the  configuration  file  must  contain  a  TASK  statement  The 
TASK  statement  declares  a  task,  which  may  be  either  a  user-supplied  task  or  one  of  the 
standard  tasks  provided  with  the  configurer.  The  following  configuration  file  lines  declares 
the  afserver  task,  filter  task,  master  task,  two  router  tasks  and  two  worker  tasks  for  our 
application: 
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task  afserver 
task  Alter 
task  master 


inssl  outssl 

inss2  outss2  dataslSk 

inssS  outssS  data=15k  Ale="tr  commt.b4'* 


taskrouterO  ins=20outss20  data=2k  Ales"router.bi’  urgent 

taskrouterl  inss20outss20  datas2k  Ales:"router.b4*'  urgent 


task  workerOO  inssl  outssl  datas27Sk  Ales"worker.t>4" 

task  workerOl  inssl  outssl  daUs275k  Ales^workerAd" 


Each  task  declaration  must  include  an  “Ins”  attribute,  which  specifies  the 
number  of  elements  in  the  task’s  vector  of  input  ports  and  an  “outs”  attribute,  which 
specifies  the  number  of  elements  in  the  task’s  vector  of  output  ports.  The  “data”  attribute 
specifies  the  amount  of  memory  which  a  task  needs.  For  example  the  filter  task  requires  a 
minimum  of  15  KByte  of  workspace.  A  user  task  for  which  no  memory  requirement  is 
specified  gets  all  the  ftee  memory  remaining  once  any  other  tasks  placed  on  that  processor 
are  loaded.  Only  one  task  on  each  processor  can  have  its  memory  requirements  left 
unspecified  in  this  way.  The  configurer  would  otherwise  have  to  decide  how  to  split  the 
remaining  memory  between  several  tasks  with  unspecified  requirements;  because  an  even 
split  is  unlikely  to  be  desirable  in  practice,  that  is  not  allowed.  The  “urgent”  attribute 
specifies  that  the  task’s  initial  thread  is  to  be  started  at  the  urgent  priority  level.  The  default 
is  that  the  task’s  initial  thread  is  started  at  the  non-urgent  priority  level.  The  “Ale”  attribute 
speciAes  the  file  in  which  the  memory  image  of  the  task  is  to  be  found.  Task  image  files  are 
produced  by  the  linker  program.  The  “file”  attribute  is  ignored  for  the  host  processor  and 
for  any  processor  for  which  the  processor  attribute  “typc=pc”  has  been  specified. 

The  placement  of  tasks  on  processors  is  specified  by  the  PLACE 
statement  It  determines  which  processor  a  particular  task  is  to  execute  on.  Every  task  must 
be  placed  on  some  processor.  The  following  configuration  file  lines  describes  the 
placement  of  the  afserver  task,  filter  task,  master  task,  two  of  the  router  tasks  and  two  of 
the  worker  tasks  for  our  application; 
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place  ahenrer 

host 

place  filter 

root 

place  master 

root 

place  routerO 

root 

place  workerOO 

root 

place  routerl 

pi 

place  workerlO 

pi 

The  CONNECT  statement  establishes  a  channel  between  two  tasks,  by 
connecting  an  ouq)ut  port  to  an  input  port  Because  channels  (unlike  wires)  are 
unidirectional,  two  CONNECT  statements  are  needed  to  create  channels  going  in  both 
directions  between  two  tasks.  The  following  configuration  file  lines  describes  the  channels 
between  the  afserver  task,  filter  task,  master  task,  two  router  tasks  and  one  router-one 
worker  tasks  for  our  application: 


connect  ?  afserverlO] 

filter[0] 

connect  ?  filter[0] 

afserver[0] 

connect  7  ftlter(l] 

master[l] 

connect  ?  niaster[l] 

filter[l] 

connect  ?  niaster[2] 

router0[0] 

connect  ?  router0[0] 

ma8ter[2] 

connect  ?  routerO[l] 

routerl  [0] 

connect  ?  routerl  [0] 

routerOjl] 

connect  ?  router0[4] 

worker00[0] 

connect  7  worker00[0] 

router0[4] 

The  CONNECT  keyword  can  be  followed  by  an  identifier  naming  the 
connection,  but  all  the  configuration  statements  which  declare  new  identifiers  allow  a 
question  mark  to  be  used  in  place  of  the  identifier  being  declared.  This  is  useful  when  there 
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is  no  need  to  refer  to  an  object  after  it  has  been  declared.  After  the  identifier  (or  question 
mark)  the  output  port  is  coded  first,  and  then  the  input  port  is  coded. 

And,  finally  the  BIND  statement  allows  the  contents  of  a  port  to  be 
explicitly  set  to  some  literal  value.  Normally,  ports  rre  only  bound  by  means  of  the 
CONNECT  .statement:  ports  left  unbound  are  pointed  at  unique  transputer  channel  words 
so  that  attempts  to  send  or  receive  messages  through  them  cause  the  minimum  harm;  the 
thread  causing  the  attempt  to  communicate  over  the  unbound  port  simply  pauses 
indefinitely  rather  than  causing  failure  of  possibly  all  threads  running  on  the  processor.  One 
application  of  the  BIND  statement  is  to  give  a  task  access  to  the  transputer’s  external  event 
mechanism.  This  appears  as  a  channel  word  at  a  specific  address.  Another  application  of 
the  BIND  statement  is  to  pass  an  integer  parameter  to  a  user  task.  We  used  the  first 
application  and  initialized  the  “input  port  4”  and  “output  port  4”  of  the  master  task  to  point 
to  that  channel  woi  $  at  the  addresses  which  are  shown  in  the  following  configuration  file 
lines: 


bind  input  niaster{4] 
bind  output  niaster[4] 


values&B 

values&B 


111  I  I  I 


1C 

c 


The  configuration  files  help  to  create  a  parallel  application  for  a  multi¬ 
transputer  system  with  a  fixed  hardware  configuration.  For  our  plication,  the  fixed 
hardware  configuration  was  shown  in  Figure  4. 19  of  the  hardware  part  of  this  chapter.  Our 
configuration  file  btestlSO.cfg  is  listed  in  Appendix  B  and  Figure  4.24  shows  our  multi¬ 
transputer  system  application  i.e.  current  topology  for  transputers. 

c.  Loading  the  Height  Data 

The  Pegasus  Database  has  all  the  terrain  height  data,  as  we  detailed  in  Chapter 
m.  Because  of  the  memory  limitations  of  CTTRAMs  (each  of  them  has  4Mbyte  RAM),  we 
can  read  and  load  the  height  data  for  a  limited  area  at  a  time. 
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In  our  application  program,  ^ve  use  an  5120  x  2304m.  terrain  which  includes 
the  training  area  whose  UTM  coordinates  are  54000  *  59000  WE  and  78000  -  80000  SN 
and  PVDB  coordinates  are  10692  -  15672  WE  and  14096  -  16096  SN.  This  area  was 
selected  because,  its  vegetation  has  the  desired  characteristics  for  a  tank  battle  training. 

The  loading  process  occurs  in  two  basic  steps.  First,  the  data  is  read  by  the  Sun 
SPARC  Station  from  Pegasus  Database  and  then  transferred  (loaded)  to  CTRAMs.  Pegasus 
Database  is  accessible  through  the  Phoenix  Server  which  is  not  a  member  of  our  department 
Local  Area  Network.  However,  the  Pegasus  Database  was  mounted  through  NFS  (Network 
File  System),  so  the  database  can  be  simply  accessed  by  a  read  function.  But,  most  of  the 
time  is  still  spent  during  this  read  function.  The  source  code  which  we  use  for  this  data 
reading  is  listed  in  Appendix  C. 

For  the  second  part  of  loading  process,  if  we  call  all  data  to  be  loaded  to 
CTRAMs  as  map,  every  CTRAM  will  have  a  portion  of  that  map  in  its  own  memory  after 
loading.  The  speed  of  this  transfer  is  10  Mbits/sec  and  the  transfer  occurs  through  the  litdcs. 

The  data  are  loaded  to  totally  15  CTRAMs.  14  of  them  are  located  on  the 
BO  12  board  and  one  of  them  is  the  on  the  Remote  Tram  Holder.  Each  CTRAM  in  our 
current  system  has  a  4Mbyte  memory.  Since  the  router  occupies  some  memory  in  each  of 
them,  we  can  load  at  most  15  blocks  (256Kbyte  each)  to  one  CTRAM.  But,  to  use  as  many 
transputers  as  we  can  for  efficient  calculation  and  meanwhile  to  load  those  CTRAMs 
equally,  we  usel5  CTRAMs  and  each  of  them  has  12  blocks.  In  each  CTRAM,  12  blocks 
are  loaded  to  12  different  workers.  These  workers  arc  the  smallest  portions  in  which  an 
LOS  calculation  occurs.  Figure  4.25  shows  the  map  we  load  at  a  time  and  the  distribution 
of  blocks  to  CTRAMs. 


69 


Figure  4.24:  Current  Topology  of  the  Transputers 
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Figure  4.25:  The  Map  Siz*.  ?nd  the  Distribution  of  Blocks  to  CTRAMs 


d.  LOS  Calculation 

The  LOS  calculation  request  between  two  points  is  made  by  a  server  that 
represents  JANUS  system.  The  information  about  the  start  and  goal  points  is  sent  to  Sun 
SPARC  Station  using  the  link  communication  established  between  them  (the  program 
which  is  used  for  this  purpose  is  listed  in  Appendix  A  as  client.main.C).  Then,  this 
information  is  broadcasted  by  the  Sun  SPARC  Stadon  to  the  transputers  after  receiving  the 
point  information. 

The  LOS  calculation  is  made  in  each  of  the  transputers.  Since  each  transputer 
knows  the  borders  ofii^  map  portion,  the  transputers  whose  map  portions  don’t  include  the 
coordinates  of  tho.^  tv  o  points  and  of  the  line  between  them  returns  “0”  as  an  answer 
automatically.  The  transputers  whose  map  portions  include  the  coordinates  of  those  two 
points  and  of  the  line  between  them  make  LOS  calculations  for  their  map  portions,  and 
return  “0”  if  LOS  exists  or  “1”  otherwise.  Tlien  all  the  answers  from  transputers  are  added. 
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and  if  the  total  is  “0”,  that  means  LOS  exists  between  them,  but  if  the  total  is  greater  than 
or  equal  to  “1”,  that  means  LOS  doesn’t  exist  between  them.  This  answer  is  sent  to  the 
server  that  represents  JANUS  by  way  of  Sun  SPARC  Station. 

e.  The  Af server  Test  on  Host 

The  afsCTvcr  task  is  an  ordinary  MS-DOS  executable  (.exe)  file  that  runs  on 
the  PC.  It  loads  executable  .b4  files  into  the  transputer  aitd  also  acts  as  a  file  server, 
handling  I/O  requests  made  by  the  uansputer.  The  afserver  and  the  transputer  execute  in 
p:  "allel  and  communicate  via  an  Inmos  link.  The  messages  sent  to  the  afserver  are  normally 
generated  by  the  Parai.’  run-time  library.  It  converts  I/O  operations  into  messages 

requesting  the  afserver  to  perform  MS-DOS  operations  and  then  waits  for  the  afserver  to 
reply. 

In  principle,  the  afserver  task  could  be  directly  connected  to  the  user  program. 
In  practice,  a  filter  task  is  interposed  between  them.  The  filter  runs  in  parallel  with  the 
afserver  and  the  user  task;  it  simply  passes  on  messages  travelling  in  both  directions.  The 
filter  is  required  because  sometimes  the  messages  passed  between  the  user  program  and  the 
afserver  are  only  one  byte  long  and  the  revision  chip  cannot  handle  single-byte  message 
transfers  on  its  hardware  liitks.  The  filter  pads  out  1  -byte  messages  to  2  bytes  to  avoid  this 
problem.  The  connections  for  afserver  and  filter  tasks  can  be  seen  in  btestlSO.cfg 
configuration  file  which  is  listed  in  Appendix  B. 
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V.  EXPERIMENTAL  RESULTS  FOR  LINE-OF-SIGHT 

CALCULATION 


A.  PERFORMANCE  ANALYSIS 

When  a  line-of-sight  request  is  received  by  our  system,  the  information  about  start 
and  goal  points  is  broadcasted  to  all  transputers  in  the  network.  Since  each  transputer  has 
height  data  for  a  different  portion  of  all  area.  LOS  calculations  are  done  only  by  the 
transputers  along  the  line  between  start  and  goal  points.  The  advantage  of  parallelism  for 
our  application  is  that  each  transputer  starts  doing  LOS  calculations  at  the  same  time.  So, 
when  we  neglect  the  time  spent  for  communications  between  transputers,  the  total  LOS 
calculation  time  for  all  transputers  which  participate  the  calculation  should  be  equal  to  the 
time  spent  by  the  transputer  which  does  maximum  LOS  calculations. 

The  most  important  factor  for  measuring  performance  increase  with  our  parallel 
system  is  the  distance  between  the  two  points  which  are  subjects  to  LOS  calculation.  If  the 
distance  between  those  two  points  is  too  short  and  only  cne  transputer  does  the  calculation, 
then  this  is  the  worst  case  and  we  have  no  performance  gain  when  we  compare  with  a  one 
processor  system.  If  the  distance  between  those  two  points  is  maximum,  which  is  equal  to 
the  diagonal  of  the  simulation  area,  then  this  is  the  best  case  and  the  perfomiance  gain  is 

Jn  where  n  represents  the  number  of  processors  (transputers). 

So,  ideally  the  expected  average  gain  after  some  number  of  consecutive  LOS 
calculations  will  be: 

EXPECTED  AVERAGE  GAIN  «  y  (Eq  5.1) 

And  the  expected  average  utility  of  the  system  will  be: 

EXPECTED  AVERAGE  SYSTEM  UTILITY  «  ~/n  -  -L  (Eq  5.2) 

^  ijn 
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Since  we  used  15  transputers  in  our  application,  by  using  Eq  5. 1  and  Eq  5.2  we  can 
say  that  the  expected  average  gain  of  our  system  is  ( (./is)  /2)  -  1.936  and  the  expected 
average  system  utility  is  (1/  (2711) )  ■  0.129 . 

B.  THE  RESUl.TS 

In  order  to  test  our  transputer  implementation  of  line-of-sight  calculation,  we  had  to 
run  our  program  such  that  all  calculations  would  be  done  by  one  transputer.  Then  we  could 
direedy  make  comparison  and  see  the  improvement  But  this  could  be  possible  only  if  the 
points  between  which  the  LOS  calculation  was  required  were  inside  the  map  borders  of  that 
transputer  module.  Since  CTRAMs  had  approximately  4  Mbyte  of  limited  available 
memory  and  the  total  training  area  required  approximately  46  Mbyte  memory,  it  was 
impossible  to  do  timing  testing  with  one  transputer.  Then,  we  decided  to  use  another  Sun 

SPARC  station*  with  a  large  memory  to  hold  all  training  area  data  in  its  memory.  We  made 
a  modification  to  our  application  programs  to  run  them  on  that  Sun  station  as  being  a  non- 
transputer  or  a  non-parallel  version.  So,  every  LOS  calculation  was  done  by  a  single 
processor  whatever  the  distance  between  start  and  goal  points  were.  Then  we  could  test  our 
implementation  by  using  the  scale  factor  between  transputer  and  that  Sun  station  which  v/ill 
be  described  below. 

We  used  two  different  start  and  goal  point  pairs  for  testing.  The  height  values  for  both 
pairs  were  entered  as  big  numbers,  so  we  were  sure  that  there  was  line-of-sight  between 
start  and  goal  points.  This  was  important  to  provide  a  full  calculation  time.  Because,  the 
LOS  calculation  algorithm  stops  and  returns  the  answer  when  a  bigger  height  data  is 
encountered  before  reaching  to  the  end  point.  This  could  take  a  very  shon  time.  But,  when 
there  is  line-of-sight  between  two  points,  this  means  every  data  on  the  line  is  checked  and 
a  full  time  LOS  calculation  occurs. 

1.  The  Sun  station  we  used  was  a  SPARCsystem  630MP  Model  !20  with  128  Mbytes  memory  and 
two  40  MHz  SPARC2  processors.  Its  performance  was  25  MIPS  and  4  MFLOPS  for  our 
application.  This  performance  is  alntost  twice  of  the  performance  of  a  SPARCstaiionl  which 
features  20  Mhz  clock  speed,  12  MIPS  and  2.5  MFLOPS. 
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For  the  first  pair,  the  distance  between  start  and  goal  points  were  selected  such  that 
the  coordinates  of  the  points  renuined  inside  the  borders  of  one  transputer  module.  The 
purpose  here  was  to  allow  only  one  transputer  to  do  LOS  calculation  in  our  transputer 
implementation  and  to  get  one  transputer  LOS  calculation  time.  Meanwhile  we  used  the 

same  points  to  get  the  Sun  station  LOS  calculation  time.  These  results^  are  shown  in  Table 
5. 1  and  Table  5.2.  The  comparison  between  two  calculation  times  gave  us  the  scale  factor 
between  transputer  and  Sun  station: 


SCALE  FACTOR  « 


TRTIMEX 

SUNTIMEl 


1.117 


For  the  second  pair,  the  distance  between  start  and  goal  points  were  selected  as 
maximum  (as  the  diagonal  of  the  area).  The  purpose  here  was  to  allow  as  many  transputers 
as  we  could  to  do  LOS  calculation  in  our  transputer  implementation.  We  also  used  the  same 

points  to  get  the  Sun  station  LOS  calculation  time  for  a  maximum  distance.  These  results^ 
are  shown  in  Table  5.3  and  Table  5.4.  Then,  we  simulated  a  transputer  with  enough 
memory  to  hold  all  ntap  data  by  using  the  SCALE  FACTOR,  named  that  simulated  time  as 
SIMTRTTME2  and  found  the  SPEEDUP  RATIO  for  the  best  case  of  our  implementation: 


SIMTRTIME2  -  SCALE  FACTOR xSUNTlME2  »  lg.956 


SPEEDUP  RATIO 


SIMTRTIME2 

TRHME2 


2.581 


2.  These  dming  results  are  for  100  consecutive  LOS  calculadons  of  each  point. 

3.  These  dining  results  aie  for  100  consecutive  LOS  calculations  of  each  point. 
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TABLE  5.1:  THE  TIMING  RESULTS  OF  TRANSPUTER  VERSION  FOR  SHORT 
DISTANCE  (LIMITED  TO  ONE  TRANSPUTER) 


TEST 

NO 

START  POINT  PVDB 
COORDINATE 

END  POINT  PVDB 
COORDINATE 

LOS 

RESULT 

TIME(8Cc) 

1 

10672, 14096 

11695, 14683 

0 

5.995 

2 

10672,  14096 

11695, 14683 

0 

5.983 

3 

10672, 14096 

11695, 14683 

0 

5.974 

AVERAGE  TIME  »  TRTIMEl  -5.984 


TABLE  5.2:  THE  TIMING  RESULTS  OF  NON.PAR  ALLEL  VERSION 
(SUN  station  VERSION)  FOR  SHORT  DISTANCE 


TEST 

NO 

START  POINT  PVDB 
COORDINATE 

END  POINT  PVDB 
COORDINATE 

LOS 

RESULT 

TIME  (sec) 

1 

10672, 14096 

11695, 14683 

0 

5.250 

2 

10672,  14096 

11695, 14683 

0 

5.935 

3 

10672,  14096 

11695,  14683 

0 

4.877 

AVERAGE  TIME  -  SUNTTMEl  =  5.354 
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TABLE  53:  THE  TIMING  RESULTS  OP  TRANSPUTER  VERSION 
FOR  MAXIMUM  DISTANCE 


TEST 

NO 

START  POINT  PVDB 
COORDINATE 

END  POINT  PVDB 
COORDINATE 

LOS 

RESULT 

TIME  (see) 

1 

10672, 14096 

15672, 16096 

0 

7.337 

2 

10672,  14096 

15672, 16096 

0 

7.356 

3 

10672, 14096 

15672,  16096 

0 

7.337 

AVERAGE  TIME  -  TRTIME2  *  7.343 


TABLE  5.4:  THE  TIMING  RESULTS  OF  NON-PARALLEL  VERSION 
(SUN  STATION  VERSION)  FOR  MAXIMUM  DISTANCE 


TEST 

NO 

START  POINT  PVDB 
COORDINATE 

END  POINT  PVDB 
COORDINATE 

LOS 

RESULT 

TIME  (sec) 

10672,  14096 

15672, 16096 

0 

17.028 

10672, 14096 

15672,  16096 

0 

17.226 

10672, 14096 

15672,  16096 

0 

16.661 

AVERAGE  TIME  =  SUNTIME2  «  16.971 
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The  communication  overhead  slowed  down  the  processing  time  of  transputers.  The 

ratio  between  the  expected  best  case  gain  which  was  Jn  and  the  SPEEDUP  RATIO  showed 
us  the  maximum  communication  overhead  between  the  transputers.  We  found  that  we  had 
33.3  percent  of  communication  overhead  as  a  maximum  value  for  our  system: 

SPEEDUP  RATIO 

JTs 

Ihe  next  step  was  to  determine  the  average  gain  and  the  average  communication 
overhead  for  the  system.  First,  we  had  to  find  the  average  LX)S  calculation  times  for  both 
transputers  and  the  Sun  station  to  do  that.  We  kept  the  lower  left  comer  of  the  map  as  the 
start  point  and  used  a  random  number  generator  to  generate  SO  different  goal  points  for 
LOS  calculations.  We  used  these  SO  pairs  of  points  for  our  transputer  system  and  for  the 

Sun  station.  The  results^  were  as  follows: 

AVERAGE  LOS  CALCULATION  TIME  FOR  TRANSPUTERS  »  6.541soc 

AVERAGE  LOS  CALCULATION  FOR  SUN  STATION  «  8.89sec 

Then,  by  using  these  two  average  time  values  and  the  SCALE  FACTOR,  we  found 
the  AVERAGE  GAIN: 


MAXIMUM  COMMUNICATION  OVERHEAD  -  1  - 


AVERAGE  GAIN  ■  8.89  x SCALE  FACTOR 

6.541 


1.518 


4.  These  timing  results  are  fori 00  consecutive  LX>S  calculations  for  each  SO  points. 
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And,  the  comparison  of  EXPECTED  AVERAGE  GAIN  which  was  (Jn)  /2  and  the 
AVERAGE  GAIN  gave  us  the  average  communication  overhead  between  the  transputers. 
We  found  that  we  had  about  21.5  percent  of  communication  overhead  as  an  average  value 
for  our  system; 

AVERAGE  COMMUNICATIOS  OVERHEAD  -  ■  0-215 

Finally,  we  calculated  the  average  system  utility  for  our  application: 


AVERAGE  SYSTEM  UTILITY 


AVERAGE  GAIN 


0.1012 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

This  thesis  was  an  effort  to  improve  Janus  combat  simulation  model  in  a  distributed 
memory  and  computing  environment  using  transputers  and  PEGASUS  1 -meter  resolution 
database.  We  have  shown  that  line-of-sight  (LOS)  calculation  can  be  done  using  a  muld 
transputer  system  with  some  modifications  in  the  processor  farming  idea. 

Due  to  the  memory  limitations  placed  on  us  by  the  Sun  SPARC  station^  that  we  used 
in  our  application,  we  had  to  place  12  worker  tasks  on  each  transputer  in  the  network.  The 
number  of  worker  tasks  could  be  less  only  if  the  Sun  SPARC  station  could  keep  bigger  map 
data  in  its  memory  during  each  data  loading  process  to  the  transputers.  Because  of  the  big 
number  of  worker  tasks,  we  had  a  high  communication  overhead  which  affected  the 
performance  of  our  application. 

Although  the  performance  increase  is  less  than  the  expected  values,  the  timing  results 
have  shown  that  further  significant  improvements  can  be  provided  for  LOS  calculation 
time  with  faster  transputers  and  a  Sun  SPARC  station  that  has  more  memory. 

B.  RECOMMENDATIONS  FOR  FURTHER  RESEARCH 

The  further  research  opportunities  can  be  classified  under  the  following  main  topics: 

1.  Connection  To  Janus 

In  ideal  conditions,  the  line-of-sight  calculation  requests  should  be  made  by  Janus 
system  itself  and  the  start  and  goal  point  information  should  be  provided  to  Sun  SPARC 
station.  But  Janus  is  not  available  in  NPS  Computer  Science  Departnvnt  yet  After  the 


1 .  The  Sun  SPARC  station  in  our  application  (see  Figure  4.23)  is  a  SFARCstation  IPX  with  16 
MBytes  memory. 
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completion  of  setting  up  the  Janus  in  our  department,  the  future  work  will  be  providing  the 
connections  between  our  application  and  the  Janus  system  and  make  them  work  together. 

2.  INMOST9000  Transputers 

The  INMOS  T90(X)  [Ref.  6:p.  351]  is  the  latest  member  of  the  transputer  family. 
It  is  designed  to  provide  far  higher  performance  and  greatly  improved  communication 
facilities.  INMOS  has  used  advanced  CMOS  technology  to  integrate  a  32-bit  integer 
processor,  a  64- bit  floating  point  processor,  16  Kbytes  of  cache  memory,  a  communications 
processor  and  four  high  bandwidth  serial  communications  links  on  a  single  IMS  T9000 
chip.  The  IMS  T9000  transputer  excels  in  real-time  embedded  applications,  delivering 
exceptional  single  processor  performance  and  scalable  multiprocessor  capability.  In 
addition  to  executing  several  instructions  each  cycle,  the  number  of  cycles  required  to 
perform  many  arithmetic  and  logical  operations  has  been  reduced  from  previous 
transputers  by  adding  extra  hardware.  Because  of  its  superior  characteristics,  IMS  T9000 
should  improve  our  system  performance  significantly. 

3.  ALPHA  AXP  Farm  Programming  Environment 

Alpha  AXP  Farms  which  are  produced  by  Digital  Equipment  Corporation  are 
another  choice  for  distributed  memory  parallelism.  They  also  provide  tools  and  libraries  for 
farms.  These  AXP  Farms  use  DECchip  21064  (Alpha  AXP  microprocessor)  which  is  the 
fastest  microprocessor  in  the  industry  [Ref.  6:p.  351).  DECchip  21064  offers  the  highest 
available  performance  with  a  400  peak  operations  per  millisecond,  a  cache  bandwidth  of 
3.2  GB/s,  controls  up  to  16  MB  cache  and  a  64-bit  design.  Therefore  we  believe  that  the 
applicability  of  Alpha  AXP  Farms  to  our  problem  can  be  a  future  research  area. 

4.  Parallel  Programming  Support  Environments 

A  parallel  programming  environment  is  a  collection  of  tools  for  automating  part 
or  all  of  the  steps  in  writing  a  parallel  program  [Ref.  6:p.  351].  A  variety  of  environments 
and  tools  have  been  proposed,  prototypes  constructed,  and  a  few  commercially  available 


81 


systems  maiketed  to  parallel  programmers.  Among  these  EXPRESS  [Ref.  6:p.  351]  and 
The  HELIOS  [Ref.  6;p.  351]  are  available  in  our  laboratory. 

EXPRESS  is  a  collection  of  routine  calls  that  form  a  toolbox  for  writing 
distributed-memory  parallel  programs.  The  toolbox  routines  are  used  as  built-in  functions 
to  distribute  data  among  processors  and  coordinate  processors  during  parallel  program 
execution.  EXPRESS  has  been  implemented  on  Intel,  Mark  m,  nCUBE,  and  transputer- 
based  machines  [Ref.  6:p.  351]. 

The  HELIOS  Parallel  Operating  System  has  been  designed  to  run  on  parallel 
computers.  Such  computers  contain  processing  units,  and  fast  communication  between  the 
processors.  Many  such  parallel  computers  are  built  using  transputers,  and  Helios  runs  on 
these  machines.  However,  Helios  also  runs  on  parallel  computers  built  using  processors 
other  than  transputers. 

So,  another  future  research  area  is  to  check  the  applicability  of  these  parallel 
programming  support  environments  to  our  problem  and  to  investigate  how  much 
improvements  they  car.  provide  for  us. 
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APPENDIX  A  -  SUN  SPARC  STATION  SOURCE  CODE 


This  appendix  contains  the  source  listings  of  the  €++  code  developed  for  the  Sun 
SPARC  station  that  is  used  in  this  thesis.  They  are  stored  in  files  as  listed  below: 

I. link.h 

2.  hsilink.h 

3.  los_com.h 

4.  los_global.h 

5.  map.h 

6.  map_c.h 

7.  nriap_s_com.h 

8.  s_comm.h 

9.  unix_comm.h 

10.  vector.h 

II.  map.C 

12.  map_c.C 

13.  inap_s_com.C 

14.  s_conim.C 

15.  vector.C 

16.  manager.C 

17.  client_main.C 
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FILENAME . :  link.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . ;  September  1993 

DESCRIPTION . :  ContaiiLS  the  description  of  link  communication  functions  which  are  written  in  C 


/*  Writes  "Count  "  bytes  from  ‘'Buffer**  to  the  specified  link.  “Linkld**  is  a  valid  link  identifier. 
‘Timeout’’  is  a  non-negative  integer  representing  tenths  of  a  second.  A  ‘Timeout”  of  zero  is  an  infinite 
timeout.*/ 

extern  “C”  int  WriteLinkfint  Linkld.  char*  Buffer,  int  Count,  int  Timeout); 

r  Reads  "Count"  bytes  into  “Buffer”  from  the  specified  link.  •/ 
extern  “C”  int  ReadLinkfint  Linkld.  char*  Buffer,  int  Count,  int  Timeout); 

/*  Ready  the  link  associated  with  “Name”.  */ 
extern  “C”  int  OpenLinkfchar*  Name); 

r  aoses  the  active  link  ‘Xinkid".  */ 
extern  “C”  int  CloseLinkfint  Linkld); 
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FILENAME . :hsilink.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cm  Ali  DUMJAR 

DATE . :  September  1993 


DESCRIPTION . ;  Header  file  which  provides  die  necessary  library  functions  for  link 


/*  @(#)  Module:  hsilink.h.  revision  1.0  6/2/92  */ 

#include  <sys^occoin.h> 

idefuie  h  ‘h'  /*  the  h  actually  means  nothing  as  used  here  */ 

r 

*  I/O  controls 

*/ 

struct  HSI_SETF  | 
unsigned  int  op:  16; 
unsigned  int  val;  16; 

I: 

union  HSIJO  j 
struct  HSI_SETF  set; 

I; 

#derine  RESET  (1) 

#derine  ANALYSE  (2) 

#dcrine  SETTIMEOUT  (3) 
idcftneTESTERROR  (4) 

#defineTESTREAD  (5) 

♦define  TESTWRITE  (6) 

r 

*  _IOW  write  instructions  to  the  kernel  within  the 

*  ioctl  command  code. 

•/ 

♦define  SETFL AGS  _10W(h.  1 .  onion  HSI.IO) 

/• 

*  End  of  hsilink.h 

•/ 
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/**••••••••••• 

FILENAME . 

AUTHOR . 

DATE . 

DESCRIPTION 


:  Io6_com.h 

:  Dr.  Sc-Hung  KWAK  &  Ccm  Ali  DUNDAR 
:  September  1993 

Header  file  for  two  stnicts.  One  of  them  is  for  information  about  map  and  the 
other  is  for  information  about  two  points  in  the  area. 

. . I 


#ifndefLOS_COM_H 

#(IefineLOS_COM_H 


tinclude  “vector.h" 


!*  Contains  the  lower  left  comer  coordinates,  the  size  and  the  grid  size  of  map  portion  which  is  sent  to 
tr.tAbputers  at  a  time.  */ 
struct  MAi^.r^Ot 
int  stan_x.  j  -x ;  .  ie_x.  size_y: 
double  gTid_8  /  c . 

I: 


/*  Contains  two  vectors  which  have  the  information  of  two  points  between  which  LOS  calculation  is 
made.  */ 

struct  CMD_INFO| 
vector  start,  goal; 

I: 


#endifIX)S_COM_H 
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FILENAME . :  los_global.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Ccm  Ali  DUNDAR 

DATE . :  Sqitember  1993 

DESCRIPTION . :  Defines  three  global  values  used  in  the  program. 

/*  Defines  that  the  size  of  a  map  ptntion  which  is  sent  to  transputers  at  a  time  is  2S6m.x2S6m.  */ 
#defineMAP_SIZE2S6 

t*  Defines  that  the  grid  size  showing  the  resolution  is  Im.  */ 

#defineGRID_SIZE  1.0 

/*  It  is  assumed  that  the  beginning  and  end  points  of  a  line  in  the  area  are  10m.  above  the  terrain.  V 
#define  AGENT.HEIGHT  10.0 
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t 

FILENAME . :  fnap.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Header  file  for  the  declarations  of  the  map  class  and  the  map  class  functions. 

. . . 


#ifndefMAP_H 
#define  MAP_H 
#include  “vector.h" 

class  map  { 
public: 

struct  map.repi 

int  stait_x.  start_y,  size_x.  size_y; 
double  grid.size; 
int*  data; 
int  refs: 

map_rcpO  (refs  -  1;} 

): 

map_rep  ‘p; 

mapO't  I*  ConsD  uctors  ♦/ 

mapfint  start.xint  start_y,int  size_xint  size ^.double  grid.sizejnt*  data); 

map(const  map&  map);  /*  Copy  constructor  */ 

map&  operator^const  map&  map);  I*  Assignment  operator  */ 

-mapO; 

/*  Gets  the  lower  left  comer  coordinates,  the  size  and  the  grid  size  information  of  map.  */ 

int  get_stan_x()  (return  p->start_x;): 

int  get_start_yO  (remm  p->start_y;); 

int  gct_size_xO  (return  p->size_x;); 

int  get_size_yO  (return  p->sizc_y;); 

double  get_grid^sizcO  (return  p->grid_size; ) ; 

int*  gct.dataO  (return  p->data;); 

vector  to_map_coord(vector  loc); 
int  higher_than(vector&  loc); 
int  teiTain_height(int&  grid.x,  int&  grid_y); 
int  map.post(int  grid_x,  int  grid_y); 

): 


#endif  MAP.H 
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FILENAME . 

AUTHOR . 

DATE . 

DESCRIPTION 


:  inap.c.h 

:  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 
:  September  1993 

:  Header  file  for  the  source  code  which  constnicts  the  map  portion  to  be  sent  to 
transputers  at  a  time. 


#ifhdefMAP_C_H 
•define  MAP_C_H 


•include  “map.h” 

class  map.c;  public  map  { 

public: 

inap_c(  int  stait_x.  int  start_y.  int  size_x.  int  size_y.  double  grid_sizc); 
map  map_c_to_mapO;  /*  only  x.y  are  used  •/ 

): 


•endifMAP.C.H 
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FILENAME . :  inap_s_coni.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESGUPTION . ;  Header  file  far  the  source  code  written  for  sending  the  map  poaions  to 


transputers. 


#ifndefMAP_CX)M 

#defineMAP_CX)M 


7 


#include  "los.com.h” 
tinclude  “map.c.h" 
tinclude  “s.comm.h” 

class  map_s_com{ 

MAP_INFO  map_info: 
public; 

map_s_comOI ): 

void  inap_send(int  n_tr.  int  n_pro,  map&  map,  s_comm&  s_comml);  /•  Sends  map  portions.  •/ 

I; 

#en<IifMAP_CX)M 
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FILENAME . :  s.comm.h 

AUTHOR . :  Dr.  Sc-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  Sepcember  1993 

DESCRIPTION . :  Header  file  for  the  source  code  which  performs  the  link  communication  between 

SUN  station  and  the  transputers. 


7 


#iiKlude  “link.h" 


#include  *iisilink.h'' 

#ifhdefS_COMM_H 

#defineS_COMM_H 


const  int  ROUTER_INIT  =  1; 
const  int  SEND  *  2; 
const  int  BCAST  •  3; 
const  int  LISTEN  «  4; 
const  int  TERMINATE  *  5; 


class  s_comm  ( 
int  out.link.num; 
int  in_link_num: 
int  out.Unk; 
int  injiitk; 
public: 

s_commO  1 1; 

s_comm(int  out_liftk_numl.  int  injink_numl); 

-^.commOl  CloseLink(out_link);  CloseLink(inJink);  }; 

int  routerJnit(int  num_trs,  int*  trs,  int*  unders,  int*  prs,  int  timeout): 

int  send(int  dst,  int  nts,  int  size,  char*  buf.  int  timeout);  /*  Plain  send.  */ 

int  send_i(ini  dst,  int  nts,  int  size,  char*  buf,  int  timeout);  /*  Send  integers.  */ 

int  bcast_d(int  size,  char*  buf,  int  timeoutf);  /*  Send  doubles  (byte  convert).  */ 

int  listen(int  timeout);  /*  Byte  conversion.  */ 

int  tenninate(int  timeout); 

/*  Conversion  functions  for  litile-indian(transputer)  and  big*indian(SUN)  problem.  */ 
void  convert4(char*  bufl,  char*  bufZ); 
void  convert_i_arTay(int*  bufl ,  int*  buf2,  int  size); 
void  convett8(char*  bufl ,  char*  buf2); 
void  convert_d_aiTay(double*  bufl.  double*  buf2.  int  size); 

I: 


#cndifS_COMM_H 
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FILENAME . :  uiux_comm.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Header  file  for  the  link  communication  functions  between  two  SUN  Stations. 


#<lefineSERVER_PORT_NUMBER  1053 
#dcfineCLIENT_PORT_NUMBER  1053 

f*  Link  communication  functions  from  “C  lifanry”  for  sender  */ 
extern  "C”  int  open_stream_s  (int  poft_number);  /•  Opens  link  •/ 

extern  “C"  int  send_buf_s(cbar*  buf,  int  size);  /*  Sends  buffer  •/ 

extern  “C”  int  receive_buf_s(char*  buf,  int*  sizep);  /*  Receives  buffer  •/ 
extern  “C"  int  clo3e_scream_s  (void);  /*  Closes  link  •/ 

/•  Link  communication  functions  from  C  library”for  receiver.  •/ 
extern  “C”  int  open_siream_c  (char*  host.name,  int  port_numbcr);  /•  Opens  link  */ 
extern  “CT  int  send_buf_c(char*  buf,  int  size);  /*  Sends  buffer  •/ 

extern  “C"  int  roccive_buf_c(char*  buf.  int*  sizep);  /*  Receives  buffer  */ 

extern  "C”  int  close.stieam.c  (void):  /*  Closes  link  */ 
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. . . 

FILENAME . :  vector.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Ccm  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Header  file  for  the  description  of  the  vector  class  and  vector  class  operations. 

. . * . 


#ifndef  VECTOR.H 
#denne  VECTOR.H 

class  vector  ( 
double  x,y,7.; 
public; 
vectoiO: 

vectoif  double  X 1 ,  double  yl,  double  zl); 

double  get.xO  I  return  x:|; 

double  get.yO  I  return  y; ) ; 

double  get.zQ  ( return  z; ) ; 

firiertd  int  operatomf  vector  vl,  vector  v2); 

friend  vector  operator'f< vector  vl,  vector  v2); 

friend  vector  operator-fvecuv  vl .  vector  v2): 

friend  vector  operator*(double  a,  vector  vl); 

double  doqvodf vector  vl); 

double  magnitude(void); 

vector  normalizefvoid); 

I: 

#endif  VECTOR.H 
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FE£NAME :  map.C 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Ccin  Ali  DUNDAR 

DATE...„ . . . :  September  1993 

DESCRIPTION . :  This  source  code  defines  the  map  class  functions. 


iinclude 
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map::mapO  t*  ConstnK«)r  */ 

I 

p  ■  new  map_rcp; 

p->siart_x  »  0;  p->stait_y  *  0:  p->size_x  =  0;  p->size_y  =  0; 
p->gnd_size  »  0.0. 
p->data»0;  //null pointer 
I 

map::map(int  stait_x.int  start_y,int  size.xint  sizc_y .double  grid_suje4nt*  data)  I*  Constructor  •/ 

{ 

p  «  new  map_rep; 

p->start_x  «  start_x;  p->siait_y  ■  stan_y; 
p->sitc_x  ■  sixe_x;  p->size_y  *  size_y; 
p->grid_size  *  grid.size; 
p-xlata  B  fiata; 

I 


map;:inap(const  inap£  map)  /*  Copy  constructor  */ 

{ 

niap.p->refs-M-; 
p  «  map.p; 

\ 


inap&  map::operatorB(const  map&  map)  /*  Assignment  operator  */ 

( 

map.p->refs++: 
if  (-p->ref8  ■■  0)  1 
deleteU  p->data; 
delete  p: 

» 

pB  map.p; 
return  *this: 
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inap::~inapO  /*  Destructor  •/ 

I 

if  (-(p->refs)  —  0)  I 
deleteO  p-xlata: 
delete  p; 

) 

I 


vector  inap::to_map_coonl(vector  kx:) 

vector  map_offset(((double)p->stan_x)*p->grid_sizc, 
((double)p->start_y)*p*>grid_si2e.O): 
vector  loc_wit_map  »  kx  •  map_of!set; 
retuni  (loc_wit_fnap); 

I 

int  inap::higher_than(vector&  kx) 

I 

int  grid_x  =  (int)  ((loc.get.xQ  -  p->start_x*p->grid_siic)/p->grid_size): 
int  grid_y  » (int)  (Ooc.get_yO  -  p->start_y*p.>grid_sizc)/p->grid_size); 
int  height »  p->da)ta(grid_y*p->si2e_x+grid_x]; 
return  ((double)teitain_height(grid_x,grid_>)  >  loc.get.xO): 

} 


int  map::tenain_height(int&  grid_x,  int&  gtidj^) 

{ 

return  mapj)ost(grid_x.grid_y): 

1 

int  map::mapjpost(int  gTid_x.  int  grid_y) 

( 

int  index; 

/•  index  ■  size_y*gridJoc.x  +  grid.kx.y:  */ 
index  ■  p->si2e_x*grid_y  +  grid.x; 
return  p*>daia{index]; 

I 
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FILENAME . :  iiuip_c.C 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DFSCKimON . ;  This  sowce  code  constnicts  a  map  portion  to  be  send  to  transputers  at  a  time. 


#include  <iosiream.h> 
tinclude  <fstream.h> 
finclude  <stdio.h> 

#include  •‘PVO.DEC  JT 
tinclude  "PVG.DEF.IN" 

#include  <pvdb.h> 
tinclude  “inap_c.h" 

/*  Reads  one  block  of  tenain  data  to  a  buffer  and  then  loads  elevation  data  to  data  array  of  map  portion 
by  using  the  data  in  the  buffer.  */ 

in^_c;:mn)_c(int  stajt_x,  int  start_y,int  siic_x,  ini  si2e_y,  double  grid_size) 

I 

inti; 

p  a  new  map^rep: 

P'>start_x  a  stait.x; 
p->start  _y  ■  start_y; 
p->suc_x  a  si2c_x; 
p->sire_y  =  sizejr, 

P*>grid_sizc  a  grid_size; 
p->data  a  new  int[sire_x*size_y); 

t*  One  block  of  Im.  resolution  terrain  data  is  read  to  a  buffer  here.  */ 
get_terT(RES0LUT10N_l,  start_x,  stan_y,  1); 

/*  65536  elevation  data  is  loaded  to  data  array  of  map  portion  here.  •/ 
for  (i*0:  i<65536:  i++)| 

p->data(i)=PVDB_UNPACK_ELE(TERRAIN  I  [  1  J[i)); 

» 

1 

/•  Converts  map_c  class  to  map  class.  •/ 
map  map_c::map_c_to_inapO 
I 

map  mapl(p->start_x,p->stan _y  ,p->size_x,p->size_y,p->grid_size.i)->data); 
retum(mapl), 

I 
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FILENAME . 

AUTHOR . 

DATE . 

DESCRIPTION 


:  loe.com.h 

;  Dr.  Se>Hung  KWAK  &.  Cem  Ali  DUNDAR 
:  September  1993 

:  Header  file  for  two  smicts.  One  of  them  is  for  infonnation  about  map  and  the 
other  is  for  information  about  two  points  in  the  area. 

. . *•*••**.**•••*•*•*•/ 


#ifndefLOS_COM_H 

#(iefineLOS_COM_H 


tinclude  “vector.h" 

r  Contains  the  lower  left  comer  coordinates,  the  size  and  the  grid  size  of  map  portion  which  is  sent  to 
transputers  at  a  time.  */ 
struc.'^AP  INFO{ 
ifits^  '.N  '  sizc_x,  size_y; 
doubl  ie; 

I: 

I*  Contains  two  vectors  which  have  the  infonnation  of  two  points  between  which  LOS  calculation  is 
made.  •/ 

struct  CMD_INFO( 
vector  Stan,  goal; 

I: 

#endifLOS_COM_H 
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/ 

FILENAME . :  los_gIobal.h 

AUTHOR . :  Dr.  Sc-Hung  KWAK  &  Ccm  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Defines  three  global  values  used  in  the  program. 


/*  Defines  that  the  size  of  a  map  potion  which  is  sent  to  transputers  ut  a  time  is  256m.x256m.  */ 
«defineMAP_SIZE2S6 

/*  Defines  that  the  grid  size  showing  the  resolution  is  Im.  */ 

«defineGRID.SIZE  1.0 

r  It  is  assumed  that  the  beginning  and  end  points  of  a  line  in  the  area  are  10m.  above  the  terrain.*/ 
#define  AGENT.HEIGHT  10.0 
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- - — - - - - - - - - - 

FILENAME . ;  in^>.h 

AUTHOR . :  Dr.  Se-Hiing  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  Sqjtember  1993 

DESGUPTION . :  Header  file  for  the  declarations  of  the  map  class  and  the  map  class  functions. 


#ifhdcfMAP_H 
#define  MAP.H 
iinclude  “vector.h" 

class  map  ( 
public: 

stnict  map_rcp| 

int  start.x,  start_y,  si2e_x,  size_y; 
double  grid.size; 
int*  data; 
int  refs; 

map_iepO  I  refs  «  l;J 
); 

map.rep  •p: 

mapO:  r  Conso  actors  */ 

map(int  start_xint  staft_y,int  size_x4nt  size_y .double  gTid_size4nt*  data); 

map(const  map&  map);  /*  Copy  constructor  */ 

mapdc.  operatorKconst  tnap&  map);  I*  Assignment  operator  */ 

-mapO; 

/*  Gets  the  lower  left  comer  coordinates,  the  size  and  the  grid  size  information  of  map.  */ 

int  get_start_x()  (return  p->start_x;); 

iot  get_8tart_y0  I  return  p->start_y;); 

int  get_size_xO  (return  p->size_x;}: 

irtt  get_sire_y()  ( return  p->size_y ; ) ; 

double  get_grid_sizeO  ( return  p->grid_size;  | ; 

ii*t*  get.dataO  (return  p->data;); 

vector  to_map_coord(  vector  loc): 
int  higher_than(vector&  loc); 
int  terTain_height(int&  grid.x.  int&  grid_y); 
int  map.post(int  grid_x.  int  gTid_y); 

1: 


#cndifMAP_H 
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FILENAME . 

AUTHOR . 

DATE . 

DESCRIPTION 


:  inap_c.h 

:  Dr.  Se-Hung  KWAK  &  Ctm  Ali  DUNDAR 
:  September  1993 

:  Header  file  for  the  source  code  which  constnicts  the  map  portion  to  be  sent  to 
transputers  at  a  time. 


#ifhdefMAP_C_H 
♦define  MAP_C_H 


♦include  “map.h” 


class  map.c:  public  map  ( 
public: 

map_c(  int  stait_x.  int  start _y,  int  size_x.  int  size_y.  double  grid.size); 
map  map_c_to_ma^)0;  /*  only  x.y  are  used  •/ 


#endifMAP_C_H 
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FILENAME . :  map.s.oom.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Header  file  for  the  source  code  written  for  sending  the  map  poaions  to 


transputers. 


#ifndefMAP_COM 
#denne  MAP.COM 
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#inciude  “los.com.h” 
#include  “map.c.h" 
#include  “s.comm.h" 


class  map.s.comi 
MAP.INFO  map.info; 
public: 

map.s.comOl  I; 

void  map.sendfint  n_tr.  int  njiro,  map&  map.  s_comm&  s.comml);  I*  Sends  map  portions.  •/ 

»: 


#en<lifMAP_COM 


90 


r 


FILENAME . :  s.comm.h 

AUTHOR . ;  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . ;  September  1993 

DESCRIPTION . ;  Header  file  far  the  source  code  which  performs  the  link  communication  between 

SUN  station  and  the  transputers. 


#include“link.h" 
#include  *1)s<link.h” 
#ifndefS_COMM_H 
#definc  S_COMM_H 
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const  int  ROUIER.INTT  «  1; 
const  int  SEND  «  2; 
const  int  BCAST  «  3; 
const  int  LISTEN  ■  4; 
const  int  TERMINATE  *  5; 


class  s_comm  ( 
int  out_link_num; 
int  in_link_num; 
int  out.link; 
int  in.link; 
public: 
s.commO  I 

s_conun(int  out_link_nuinl,  int  in_link_numl); 

-s.commOl  CloscLink(out_link);  CloseLink(in_link);  1; 

int  router_init(int  num.trs,  int*  trs,  int*  unders,  int*  prs,  int  timeout); 

int  send(int  dst,  int  nts.  int  size,  char*  buf,  ini  timeout);  /*  Plain  send.  */ 

int  $end_i(ini  dst,  int  nts,  int  size,  char*  buf,  int  timeout);  /*  Send  integers.  */ 

int  bcast_d(int  size,  char*  buf,  int  timeoutf);  /•  Send  doubles  (byte  convert).  */ 

int  listen(int  timeout);  T  Byte  conversion.  */ 

int  terminate(int  timeout); 

/*  Conversion  functions  for  little-indian(transputer)  and  big-indian(SUN)  problem.  */ 
void  convcn4(chai*  bufl,  char*  buf2); 
void  convcrt_i_anay(int*  bufl ,  int*  buf2,  int  size); 
void  cofivert8(char*  bufl,  char*  buf2); 
void  conveit_d_array(double*  bufl ,  double*  buf2,  int  size); 

): 


#endifS_COMM_H 


91 


FILENAME . :  unix_comm.h 

AUTHOR . ;  Dr.  S«-Hung  KWAK  &.  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIFTION . :  Heartier  file  fer  the  link  communication  functions  between  two  SUN  Stations. 

#<lefine  SERVER.  PORT.NUMBER  1053 
#(lefine  CLIENT_PORT_NUMBER  1053 

/*  Link  communication  functions  from  “C  library”  for  sender  */ 
extern  "C"  int  open_stream_s  (int  poit_number):  /•  Opens  link  •/ 
extern  “C"  int  send_buf_s(cluff*  buf,  int  size);  /*  Sends  buffer  •/ 
extern  "C"  int  receive_buf_s(char*  buf.  int*  sizep);  /•  Receives  buffer  •/ 
extern  “C"  int  close_stream_s  (void);  /•  Closes  link  •/ 

/*  Link  communication  functions  from  C  library”for  receiver.  */ 
extern  “C"  int  opcn_strram_c  (char*  host_name,  int  port_numbcr);  /*  Opens  link  •/ 
extern  “C"  int  send_buf_c(char*  buf,  int  size);  /•  Sends  buffer  */ 

extern  “C"  int  rBceive_buf_c(char*  buf,  int*  sizep);  /*  Receives  buffer  */ 

extern  “C”  int  close_stream_c  (void);  /•  Closes  link  */ 
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FILENAME . :  vecior.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Header  file  for  the  description  of  the  vector  class  and  vector  class  operations. 


#ifndefVECTOR_H 
♦define  VECTOR.H 

class  vector  ( 
double  x.v,74 
public: 
vectorO: 

vectorfdouble  xl,  double  yl,  double  zl); 

double  get.xO  (return  x;); 

double  get_yO  (return  y;); 

double  get.zO  ( return  z; ) ; 

friend  int  operatorsC  vector  vl,  vector  v2); 

friend  vector  operator-K vector  v  1,  vector  v2); 

friend  vector  operator-f vector  vl.  vector  v2); 

friend  vector  operator*(double  a,  vector  vl); 

double  dotprod( vector  vl); 

double  magnitude(void); 

vector  normalizefvoid); 

I: 

#endifVECTOR_H 
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FILENAME . :  map.C 

AUTHOR . :  Dr.  S»-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  This  source  code  defines  the  map  class  functions. 


#include  “map.h" 
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inap::niapO  Constructor  */ 

I 

p  ■  new  rtuq)_iep; 

p->start_x  »  0;  p->siart_y  ®  0;  p->sizc_x  =  0;  p->si2c_y  «  0; 
p->grid_size  «  0.0; 
p->datas0;  // null  pointer 
I 

fnap::map(int  stan_x,int  start_y.int  size.xjnt  sizc_y .double  grid.sizeont*  data)  /•  Constructor  •/ 

1 

p  ■  new  map.iep; 

p->stait_x  ■  start_x;  p->siait_y  ■  start_y: 
p->site_x  ■  size_x:  p->sttc_y  «  si7e_y; 
p->grid_size  *  grid.size; 
p->data  s  data; 

) 

map;:map(const  map&  map)  /•  Copy  constructor  •/ 

I 

map.p->rcfs++; 
p  ■  map.p; 

1 


map&  map:;operatorB(const  map&  map)  /*  Assignment  operator  *! 

I 

map.p->rcf8++; 
if  (--p->refs  *»  0)  | 
deleteU  p->data; 
delete  p: 

I 

p  s  map.p; 
return  *this; 

I 
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inap::HnapO  T  Destructor  •/ 

I 

if  (-(p->refs)  ■■  0)  I 
deleteQ  p-xlaia; 
delete  p; 

) 

} 

vector  n»p::lo_inap_coord(vector  loc) 

{ 

vector  mtp_offset(((double)p->start_x)*p->grid_si2C. 

((doublc)p->start_y)*p*>gnd_size.O); 
vector  loc_wit_inap  « loc  -  map.offset; 
retum  (loc_wit_inap); 

) 

int  map::highcr_lhan(vector&  loc) 

int  grid_x  =  (int)  ((loc.gcl_xO  -  p->stait_x*p*>grid_si2e)/p->grid_size): 
int  grid_y  ■  (int)  (aoc.get_yO  •  p->start_y*p->grid_stte)/p->grid_size): 
int  height »  p->daia(gTid_y*p->sire_x+grid_x): 
retum  ((double)tefTain_height(grid_x,gTid_>-)  >  loc.get_zO); 

1 

int  map;:tenain_height(int&  grid_x.  int&  grid_y) 

( 

return  map_post(grid_x,gTid_y): 

) 


int  map:;mapjpost(int  grid_x,  int  gTid_y) 

I 

int  index; 

/*  Lndex  ■  size_y*giid_loc.x  +  grid.loc.y;  •/ 
index  ■  p->sue_x*grid_y  +  grid.x; 
return  p->dal£{index]: 

1 


95 


. . . 

FILENAME . ;  HM»p_c.C 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Aii  DUNDAR 

DATE . :  September  1993 

DFSCkIPTION . :  This  sotsce  code  constructs  a  map  portion  to  be  send  to  tran^uters  at  a  time. 


#include  <iostream.h> 
tinclude  <fstream.h> 
iinclude  <stdio.h> 

♦include  “PVG.DEC  JT 
♦include  “PVG_DEFJN” 

♦include  ^vdb.h> 

♦include  “map_c.h" 

/*  Reads  one  block  of  terrain  data  to  a  buffer  and  then  loads  elevation  data  to  data  array  of  map  portion 
by  using  the  data  in  the  buffer.  */ 

fnap_c::mj^_c(int  stait_x.  int  start_y.int  sizc_x,  int  si2e_y,  double  grid_size) 

{ 

iftt  i; 

p  ■  ttew  map.tep: 
p->start_x  a  start_x: 
p->start_y  =  stait_y; 
p->size_x  »  size.x; 
p->si2c_j  =  sizc_y; 
p->gTid_size  «  grid.size; 
p->data  a  new  int(size_x*size_y); 

f*  One  block  of  Im.  resolution  terrain  data  is  read  to  a  buffer  here.  */ 
gct_tcrr<RESOLUTION_l.  stait_x,  start _y,  1); 

/*  65536  elevation  data  is  loaded  to  data  array  of  map  portion  here.  */ 
for  (i«0;  i<65536;  i++)( 

p->dataIi]=PVDB_UNPACK_ELE(TERRAIN  1 1 1  l(i)); 

I 

I 

/•  Converts  map_c  class  to  map  clas.s.  •/ 
map  map_c::map_c_to_mapO 
( 

map  mapl(p->start_x,p->stan_y  .p->size_x.p->size_y.p->grid_size.i)->data); 
retum(mapl); 

1 
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FILENAME . :  inap_s_cofn»C 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  Sepccmber  1993 

DESCRIPTION . :  This  source  code  is  for  sending  one  map  portion  to  transputers  thiough  the  link 


#include  ‘‘map^s^com.h’' 

#include  <iostream.h> 

void  map_s_com::map_scn(j(ini  n_ir*  im  nj)ro»  map&  map,  s_comm&  s.commi) 

{ 

MAP^INFO  mapjnfo,  map.infol; 

map_info,start_x  ■  inap.p->$tart_x; 
fnap_infc.siart_y  *  map.p->siari_y; 
inap.info.sizc_x  »  map.p->size_x; 
map_info.sizc_y  *  fnap.p->si2e_y; 

/•  Converts  double, 

solves  Uttle_indian(transputer),  big^indian(sun)  problem, 
sends  header. 

converts  siart^x,  sian_y,  size.x,  sizc^y  ♦/ 
5_comml.convcitJ_array((int*)&map_info,(ini*)&map_infol,4); 
double  X  *  map.p->grid_si2c; 
double  y; 

s_comml.convcft8((char*)&x,  (char^)&y); 
map^infoLgrid^size  *  y; 

s^comm  1  .send(n_tr.  n_pro,  stzeof(map.infol),  (char^)&map_infol.50); 

/*  Sends  real  data  (integer  is  4  chars)  */ 

s^comm  Lscnd_i(n_tr,  n_pro.  map_info.sizc_x  •  map.info.sizc_y  *  4.(chaf*)(map.p-xiata),50); 

): 
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FILENAME . :  s.coinm.C 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESGUPTION . ;  Tliis  source  code  is  for  peiforming  link  communication  between  SUN  station  and 

transputers.  It  also  has  conversion  functions  for  solving  the  little- 
indian(transputer)  and  big-indian(SUN)  problem. 


#iitclude  <iostream.h> 
tinclude  *'s_comm.h” 

f*  Opens  link.  •/ 

s_comm::s_comm(int  out_link_numl,  int  in_link_numl) 

I 

outjink.num  =  out_link_numl; 
injink.num  ■  in_link_numl: 

char  link_strt2]: 

iink_str(0]*  char<outJink_numl); 

link_str(ll  ■  N)': 

out,  link  »  OpenLink(link_str); 

if  (out_Unk_numI  !■  in_link_numl)  ( 

Unk_sir(0]«  char(in_link_numl); 
link_str(ll  - 

in  Jink  «  OpenLink(link_str); ) 
else 

in  Jink  =  out_link; 


r  Does  router  initialization  for  transputers.  */ 

int  s_comm;:router_init(int  num.trs,  int*  trs,  int*  unders,  int*  prs.  int  timeout) 

I 

int  code  ■  ROUTER_iNrT; 
int  val; 

conven4((cl»ar*)&code,  (char*)&val); 
if  (WriteLink(outJink,  (chai*)&val,  sizeoffint),  timeout)  <  0) 
return  -1; 

convert4((char*)&num_trs,  (char*)&val); 
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if  (WriteLink('Mit_link.  (chai*)Aval.  sizeof(int),  timeout)  <  0) 
return  •!; 
int*  vals; 

vals  ■  new  inUnum.tis]; 
convcitJ_aiTay(trs,  vals,  numj  j): 

if  (WriteLink(out_link.  (chai*)vals.  sizeof(int)*num_trs.  timeout)  <  0) 
return -I; 

conven_Lanay(un(len,  vals,  num.trs): 

if  (WriteLink(ouLlinlt.(char*)vaU.  sizeof(int)*num_lrs,  timeout)  <  0) 
return  -1; 

convenJ.airayCprs,  vals,  num.trs); 

if  (WriteLink(out_link,  <chai*)vals,  sizeof(int)*num_trs,  timeout)  <  0) 
return  -1; 
retum  1; 

) 

I*  Plain  sending.  No  conversion.  •/ 

int  s_comm::send(int  dst,  int  nts,  int  size,  chai*  buf,  int  timeout) 

I 

int  code  >  SEND; 
int  val; 

conveft4((chai*)&code,  (chaf*)&val); 
if  (WriteLink(out_link,  (chaf*)&val,  sizeof(int),  timeout)  <  0) 
retum  0; 

convert4((char*)&dst,  (char*)&val); 
if  (WriteLinlr(out.link,  (chai*)&val,  sizeof(int),  timeout)  <  0) 
return  0; 

conveft4((chai*)&nt8,  (char*)i^val); 
if  (WriteLink(outJink,  (chaf*)&val,  sizeof(int),  timeout)  <  0) 
retum  O, 

conveft4((chaf*)&size,  (char*)&val): 
if  (WriteLink(outJink.  (char*)&val,  8izeof(int),  timeout)  <  0) 
return  0; 

//  No  conversion.  Send  buf  directly 
if  (WriteLinkfoutJink,  buf,  size,  timeout)  <  0) 
retum  0; 
retum  1; 

) 
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/*  Sends  integers.  */ 

int  s_comni;:8endJ(lnt  dst.  int  nts,  int  size,  char*  buf,  int  timeout) 


int  code  *  SEND; 
int  val; 

conven4uchar*)&code.  (char*)&val); 
if  (WriteLink(ouUi*'k.  (chai*)&val.  sizeof(int),  timaout)  <  0) 
return  0; 

conven4((chai*)dtdst,  (char*)&val); 
if  (WriteLinkfouiJink.  (chai*)&val.  8izeof(int).  timeout)  <  0) 
return  0; 

conve(t4<(char*)dknts,  (char*)&val); 
if  (WtiteIink(out_Unk.  (char*)&val.  sizeoffint),  timeout)  <  0) 
return  0; 

conveit4((char*)&size.  (char*)&val); 
if  (WriteUnkfouLUnk,  (char*)&val.  sizeof(int),  timeout)  <  0) 
return  0; 
cliar*  vals: 

vals  ■  new  chart sizej; 

conveitJL4nBy((int*)buf.  (int*)vals.  size^izeof(int)): 
if  (WriteLink(out_Unk,  vals,  size,  timeout)  <  0)  { 
deleteQ  vals; 
return  0;  I 
else  ( 

deleteQ  vals; 
return  1:); 

I 

r  Sends  doubles.  •/ 

int  s.comm:;bcasi_d(int  size,  char*  buf.  int  timeout) 

I 

int  code  ■  BCAST; 
int  val; 

convert4((char*)dtcode,  (char*)&val); 
if  (WriteLink(out_link,  (char*)&val,  sizeof(int),  timeout)  <  0) 
return  0; 

conveit4((char*)&size,  (char*)&val); 
if  (WriteLink(out_link,  (char*)&val,  sizeoffint),  timeout)  <  0) 
return  0; 
char*  vals; 
valss  new  char  (size); 

convert_d_array((double*)buf,  (double*)vals,  size/sizeof(double)); 
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if  (WriteLink(ouLlink,  vals,  size,  timeout)  <  0) 
retumO; 
return  1; 

I 

y*  Reads  the  value  coming  from  transputers.  */ 
int  s_coinm::Iisten(int  timeout) 

{ 

int  code*  LISTEN: 
int  val,  result: 

ccr,ven4((char*)&to(ic,  (chaf*)&val): 
if  (WriteLifik(out_link,  (char*)&val.  sizeof(int),  timeout)  <  0) 
return  0: 

if  (ReadLink(in_Unk.  (char*)&val,  sizeof(int).  timeout)  <  0) 
return  0: 

convert4((char*)&val.(char*)&result): 
return  result: 

) 

int  s_comm::tetminaie(int  timeout) 

{ 

int  code  ■>  TERMINATE: 
int  val: 

convert4((char*)4code.  (cl»ar*)&val): 
if  (WriteLink(out_link,  (char*)&val,  sizeof(int),  timeout)  <  0) 
return  0: 
return  1: 

I 


/•  CONVERSION  FUNCTIONS  FOR  LFTTLE-INDIANCrRANSPUTER)  AND  BIO-INDIAN(SUN) 

PROBLEM  STARTS  HERE.  •/ 

void  s_comm::convert4<chaf*  bufl,  char*  buf2) 

I 

buf2(3]  -  bufl[0]: 
buf2(2]-buflll]: 
buf2[l]-bufl[2]: 
buf2[0]-bufl(3]: 

I 
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void  i.conun;:convert_Lvray(im*  bufl,  int*  buf2.  int  size) 

{ 

for  (int  iaO;  i<size: 

conven4((char*Kft(bufl  (i])).(char*)(&(buf2[i]))); 

1 

void  s_conun;:conveit8(char*  bufl.  char*  bufZ) 

{ 

buf2[7]-bufl(0]: 
buf2[6]sbufl[l]; 
but2[5)  >  bufl  [2]; 
buf2[4]-bunp]; 
buf2[3]-bufl(4]; 
bul2(2]-bufl[5]; 
bu(2[l]  -  bufl[6]; 

buf2(0)  -  bufim: 

) 

void  8_comm::conveit_d_aiTay(double*  bufl,  double*  buf2.  int  size) 

I 

for  (int  i«0;  i<size:  i++)  ( 
conveit8((char*X&(bun  [i])).(char*K&(buf2[i]))): 


I 
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FILENAME . :  voctor.C 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . ;  September  1993 

DESCRIPTION . :  This  source  code  defines  the  vector  class  operations. 


#include  “vector.h" 

#include  <math.h> 

vcctor:vectorO  (x»0.0;  y^.O;  z*4).0:); 

vector:vector(double  xl, double yl, double zl)  (x*xl:  y>yl;  z«zl;); 
int  operatof«B(  vector  vl.  vector  v2) 

I 

rctum((vl.x*»v2.x)  &.&  (vl.y*™v2.y)  &&  (vl.z*«v2.2)); 

I 

vector  operator-Kvector  vl,  vector  v2) 

I 

vector  v(v1.x4’V2.x,  vl.y+v2.y.  vl.z+v2.z); 
return  v; 

I 

vector  operator^ vector  v  1 ,  vector  v2) 

i 

vector  v(vl.x*v2.x,  vl.y-v2.y.  vl.z-v2.z); 
return  v; 

) 

vector  operator*(double  a,  vector  vl) 

I 

vector  v(a*vl.x,  a*vl.y,  a*vl.z): 
return  v; 

) 

double  vector;:dotprod( vector  v2)  /*  Dot  product  •/ 

I 

rctuTn(this->x*v2.x  +  thi8->y*v2.y  +  thi8->z*v2.z); 

) 
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double  vector:iiMgnituile(void) 

I 

ittiini(s4rt((*Uus).do(|iiod(*(his))); 

1 

vectcx.  vectcr:nonnaliee(void)  /*  Vector  nonnalization  •/ 

vector  result; 

double  mag  ■  (*this).inagnitudeO; 
if  (mag  <  1E-1(X))  I 
resultx  <■  0.0; 
lesulty  •  0.0; 
lesulLzaO.O;) 
else{ 

result  ■  (l.O/mag)  •  (‘this); 

) 

retum(msult); 

I 
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FILENAME . :  manager.C 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Ccm  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  This  is  the  main  program.  The  number  of  transputers,  wortei^  and  task 


distribution  are  defined  here.  The  user  is  asked  to  enter  the  lower  left  conier 
coordinates  of  the  Sl20m.x2304m.  map  area  first.  Then  after  loading  of  the 
whole  map  to  transputers,  the  information  about  the  two  points  in  the  area 
between  which  LOS  calculation  will  be  made  is  expected  to  be  entered  and  sent 
Grom  another  server  via  the  communication  link  established  between  them.  This 
information  then  is  sent  to  the  tranq>uters  and  the  result  is  expected  from  them. 
When  the  result  is  received,  it  is  sent  to  the  station  Grom  which  the  point 
information  comes.  This  procedure  can  be  repeated  as  many  os  the  user  wants. 

r  THIS  VERSION  OF  MANAGER.C  IS  FOR  15  TRANSPUTERS.  THERE  ARE  180  WORKERS.  •/ 

tinclude  <iostream.h> 

#include  “unix_comm.h" 

#include  <fstieam.h> 

#include  “los_com.h’’ 
tinclude  “map_s_com.h" 
tinclude  “lus.global.h” 
tinclude  “map_c.h” 

tdefine  NUM_OF_WORKERS  180  f*  Each  transputer  has  12  workers.  •/ 

int  org_x,  orgjr.  orgl_x.  orgl_y; 
int  x_counter,  y_counter.  tr_x,  tr_y; 
float  info[6]; 
int  size; 

ifstream  source: 
int  sum; 
float  los.result; 

vector  agcnt(0,0,AGENT_HEIGHT); 
double  a,b,c,x.yj;; 
int  addr  «  0; 
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int  inaifi(void) 

I 

s.oonun  s.comm  1(0.0);  //  output  link  and  input  link 

f*  Total  number  of  transputers.  */ 

const  int  total_prs  ■  IS; 

r  Total  number  of  workers.  */ 

const  int  totaLn_piw  igO; 

f*  Names  of  transputers.  */ 

static  int  tts(totaI_|«s]  ■  { 

0,1.2,11.21.111.211,1111.2111,11111.21111.111111.211111.1111111.21111111; 
r  The  number  of  children  for  each  transputer  for  the  current  topology.  */ 
static  int  unders(total_prs]  ■  (2.1. 1.1. 1,1.1. 1.1. l.l.l.l.O.O); 
r  The  number  of  workers  for  each  transputer.  */ 
static  int  prs[toial_pn]  -  {12.12,12,12.12.12.12,12.12,12.12.12.12,12.12); 

The  distribution  of  workers  to  transputers.  */ 
static  int  n_tr(totaI_n_pr]  >  ( 

0.0.0.0.0.0.0.0.0.0,0.0. 

I. l.l.l.l.l.l.l.l.l.l.l, 

II. 11,11.11,11.11.11,11,11.11,11.11. 

21.21.21.21.21.21,21.21.2U1.2U1. 

111,111.111.111.111.111.111.111.111,111.111.111. 

211,211.211.211.211.211.211.211.211.211.211.211. 

1111.1111.1111.1111,1111.1111.1111.1111,1111.1111.1111.1111. 

2111.2111,2111.2111.2111.2111.2111.211U11U111.2111.2111. 

11111.11111.11111.11111.11111.11111.11111.11111,11111.11111.11111.11111, 

21111.21111.21111.21111.21111.21111,21111.21111.21111.21111.21111,21111. 

111111.111111.111111,111111.111111,111111.111111.111111. 

111111,111111.111111,111111, 

211111.211111.211111.211111.21111U11111.21111U1111!. 

21111UinilJ11111.211111, 

1111111.1111111.1111111,1111111.1111111.1111111.1111111.1111111, 

1111111,1111111.1111111,1111111, 

21111 11.2111111.2111111.2111111.211 11  lull  11 11.211111U1111I1. 
2I11111.2111111.2111111.21I1111  ); 
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/*  Names  of  ivotken  in  each  transputer.  */ 
static  int  njirttotal_n_pr]  ■  ( 

0.1.23.4.5.6.7.8.9.10.11. 

0.U3.4.5.6.7.8.9.10.11. 

0.1.23.4.5.6.73.9.10.11. 

0.1.23.4.5.6.7.8.9.10.11. 

0.133.4.5.6.7.8.9.10.11. 

0.U3.4.5.6.7.8.9.10.11. 

0.U3.4.5.6.7.8.9.10.11. 

0.U3.4.5.6.7.8.9.10.11. 

0.133.4.5.6.73.9.10.11. 

0.133.4.5.6.73.9.10.11. 

0.133.4.5.6.73.9.10.11. 

0.133.4.5.6.73.9.10.11. 

0.133.4.5.6.73.9.10.11. 

0.133.4.5.6.7.8.9.10.11. 

0.1.23.4.5.6.73.9.10.11  ); 

s.comm  1  router_init(total_prs.trs.un<len.prs.  100); 

f*  User  enters  the  lower  left  comer  coordiriates  of  the  whole  map  here.  */ 
cout  «**ENTER  X  COORDINATE  FOR  ORIGIN  :  “  «‘Nn’; 
cin  »org_x: 

cout  «‘*ENTER  Y  COORDINATE  FOR  ORIGIN :  “  «'\n’: 
cin  »org_y: 

for  (tr_x«0:  tr_x<5:  tr_x++){ 
for  (tr_y»0*.  ir_^<3;  lr_y+4)| 
for  (x.countBTBO;  x_counter<4;  x_counter<t-»'){ 
fof  (y_countcr=0;  y_counteK3;  y_counter++)| 
org  1  _x-org_x+<tr_x*4*256)+x_counter*256: 
orgl_y^g_y+{lr_y*3*256)+y_countef*256; 

map_c  mapI(orgl_x.  orgl_y.  MAP_SIZE31AP_SIZE.GRID_SIZE); 
map  c_map; 

mapjs_com  map_s_com; 


r  Sends  map  •/ 

c_map  »  mapl.fnap_c_io_mapO: 
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r  Conversion  of  map.c  class  to  map  class  before  sending  is  done*/ 
if  (addr  <  tQ(aLn_pr)  | 

map_s_com.map_8en(l(n_tr(addrl.  n_pr[addr].  c.map,  s.conunl); 

) 

addr-t-t-;  /*  Detennines  the  worker  address  for  map  portion  to  be  sent.  */ 

I 

I 

coiit«“12  blocks  of  elevation  data  sent  to  transputer  “ 

«addr/l2«''n*; 

) 

I 

cout<<“Each  15  transputer  is  loaded  with  12  blocks  of  elevation  data  “«*\n’; 
CMD_INPO  cmd_info; 

cout«‘‘The  server  is  ready  to  receive  the  start  and  goal  point  information !” 

/*  The  communication  link  is  established  between  two  Sun  stations  here  and  the 
information  of  two  points  in  the  area  for  LOS  calculation  is  received.  */ 

/*  Opens  socket  on  server  */ 
if  (open_siream_s(SERVER_PORT_NUMBER)  <  0) 
cout  «"ErTor  open  \n": 

for(;;)| 

if  ( receive_buf_s((char*)info,&sizc)  <  0)  cout «  “Error  in  receiving  'n"; 

8>adouble<info[0]): 

b=double(info(l]); 

cadouble(info(2]): 

x«double(info[3]); 

yadouble<info(4]); 

zadouble(info(S]); 

vector  siart(a,b.c): 

Stan  «  start  +  agent; 

vector  goa](x,y,z): 
goal  ■  goal  agent; 
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cind_info  Jtait  ■  siait: 
cmd.info.goil  ■  goal; 

s.comm  1  .bcasL.<l(sizeof(cmd_info),(char*)&cfnd_info^O); 
sum  ■  s_con)ml.listen(100): 

/*  The  LOS  result  will  be  'D"  if  LOS  eusts,  or  will  be  “P  if  LOS  doesn't  exist  and  it  will  be  sent 
to  the  server  which  tq>resents  Janus.  V 
if  (sumlaO) 

los_fesuitafloat(sum/sum); 

else 

Io6_result«float(sum); 

cout «  “Sum  is  “  «  dec  «  sum  « ‘'n' « flush; 

cout «  “LOS  Result  is  “  «  dec  « los_result «  *^n’  « flush; 

send_buf_s((char*)&los_Tesult,  sizeof(float)); 


s_cofnm  1  .tenninate(SO); 


FILENAME . :  client.main.C 

AUTHOR . :  Dr.  Sc-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . ;  October  1993 

DESCRIPTION . :  This  program  tuns  in  a  server  other  than  the  one  in  which  the  main  program  runs. 


The  user  is  asked  to  enter  the  information  about  the  two  points  in  the  area 
between  which  LOS  calculation  will  be  made.This  information  is  sent  to  the 
main  server  via  the  communication  link  established  between  them.  Ideally  the 
sender  is  considered  to  be  Janus.After  sending  the  point  infonnation.  dte  result 
is  expected  from  the  main  server.  When  the  result  is  received,  it  is  displayed  on 
the  screen.This  procedure  can  he  repeated  as  many  as  the  user  wants. 


#include  <iostream.h> 

#include  “unix_comm.h" 

void  main(int  argc,  char  *argv[2]) 

I 

float  a,b.c,x.y,z; 
float  bufI6]; 
int  size; 
float  •sum; 

if  (opcn_strcam_c(argv(l),CLIENT_PORT_NUMBER)  <  0) 
cout «  “Error  open 

for  (;;)  ( 

cout «  “Enter  the  x-coordinate  of  start  point  :"«‘Nt"; 

cin  »a; 

bufl01=a; 

cout «  “Enter  the  y-coordinate  of  start  point  :”«:“vn"; 

cin  »b; 

buni]=b; 

cout «  “Enter  the  height  of  start  point 

cin  »c; 

bun21=c; 

cout «  “Enter  the  x-coordinate  of  goal  point 
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cin  »x; 
bufI3]BX; 

cout «  "Enter  the  y-coordinate  of  goal  point 
cin  »y; 
bufI41«y ; 

cout «  “Enter  the  height  of  start  point 
cin  »i\ 
bufT5]*z : 

send_buf_c((char  •)buf,sizeof(noat)'*6); 
cout « ‘Two  points  sent  to  se^vel^n”; 

receive_buf_c((char  •)buf,&sizc): 
sum  =  (float  *)buf: 

cout «  “Result  is «  ‘sum  «  “Vt”; 

cout «  “  If  you  want  to  continue,  type  ‘y’ 

char  ch; 

cin  »  ch; 

if  (ch  =  ‘n’)  break; 

I 

closc_stream_c(); 

I 
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APPENDIX  B .  HOST  COMPUTER  (PC)  SOURCE  CODE 


This  appendix  contains  the  source  listings  of  the  C-h-  code  developed  for  the  host 
computer  which  is  a  PC  that  is  used  in  this  thesis.  They  are  stored  in  files  as  listed  below: 

1.  line.h 

2.  los_conxh 

3.  map.h 

4.  map_crx.h 

5.  plane.h 

6.  rout_cmd.h 

7.  routei.h 

8.  router2.h 

9.  routcrS.h 

10.  s_los.h 

11.  tr_comm.h 

12.  vector. h 

13.  line.cpp 

14.  map.cpp 

15.  map_crx.cpp 

16.  plane.cpp 

17.  router. cpp 

18.  routert.cpp 

19.  router2.cpp 

20.  router3.cpp 

21.  sjos.cpp 

22.  tr_comni.cpp 

23.  tr_commtcpp 

24.  vector.cpp 
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25.  workCT.q)p 

26.  worker.lnk 

27.  btestlSO.cfg 
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FILENAME . :  Une.h 

AUTHOR . ;  Dr.  Se-Hung  ICWAK  &  Ccm  Ali  DUNDAR 

DATE . ;  September  1993 

DESCRIPTION . :  Header  file  for  description  of  line  equation  class  and  its  functions. 


#ifndcfLINE_H 
#<lenne  LINE.H 

#includc  “vector.h” 

class  line  (  T  ^  +  P^o  */ 

vector  Stan; 
vector  direction; 
public; 
lineO  { 1; 

line(vector  ptl.  vector  dir); 

vector get.stanO  (return  stan;); 
vector  get.directionO  ( return  direction; ) ; 

I: 

#endifLINE_H 
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FILENAME . 

AUTHOR . 

DATC . 

DESCRIPTION 


:  lae.com.h 

:  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 
:  September  1993 

:  Header  file  for  two  stnicts.  One  of  them  is  for  infonnaiion  about  map  and  the 
other  is  for  information  about  two  points  in  the  area. 


#ifndefLOS_COM.H 

#defineLOS,COMJI 


#includc  “vector.h" 


/*  Contains  the  lower  left  comer  coordinates,  the  size  and  the  grid  size  of  map  portion  which  is  sent  to 
transputers  at  a  time.  */ 
struct  MAP.INFOl 
ini  start_x.  stan_y.  sizc.x,  size_y: 
double  gnd_size; 

I: 


r  Contains  two  vectors  which  have  the  information  of  two  points  between  which  LOS  calculation  is 
made.  •/ 

struct  CMD_INFO  I 
vector  Stan,  goal; 

I; 


#endifLOS_COM_H 
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FILENAME . :  inap.h 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . ;  September  1993 

DESCRIPTION . :  Header  flle  for  (he  declarations  of  (he  map  class  and  the  ntap  class  functions. 


#ifhdefMAP_H 
#define  MAP_H 
tinclude  “vectcr.h" 
class  map  ( 
public: 

St  uctmap_rep( 

int  start ji.  start_y.  sire_x.  size_y; 
double  grid.size; 
int*  data: 
int  refs; 

map_rq)0  (refs*  1;| 

): 

map_rBp*p; 

mapO:  /*  Constructors  */ 

mapfint  start_x4nt  start_y,int  size.xint  8ize_y Rouble  grid„size4nt*  data); 

map(const  itu^tA  map);  I*  Copy  constructor  */ 

map&  operatorafconst  map&  map);  /*  Assignment  operator*/ 

-mapO; 

/*  Gets  the  bwer  left  corner  coordinates,  the  size  and  the  grid  size  information  of  map.  */ 

int  get_start_xO  {return  p->start_x;); 

int  get_8tart_y0  (return  p->8tart_y;|; 

int  get_8ize_x0  (r?lum  p->size_x;); 

int  gei_size_yO  (return  p->8ize_y:|; 

double  get_grid_sizeO  (return  p->grid.8ize;); 

int*  get.dataO  (return  p->data;}; 

vector  to_map_coord(  vector  loc); 
int  higher„than(v«ctor&  loc); 
int  terTain_height(int&  grid.x,  int&  grid_y); 
int  map4X>st(int  grid_x,  int  grid_y); 


#endifMAP_H 
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FILENAME . 

AUTHOR . 

DATE . 

DESCRIPTION 


;  fnap_crx.h 

:  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 
:  September  1993 

:  Header  file  for  the  source  code  which  checks  whether  LOS  passes  through  a  map 
contained  in  a  transputer. 


#ifndefMAP_CRX_H 
#define  MAP_CRX_H 


#include  ‘'plane.h” 
#include  “map.h” 


class  map.crx  ( 

double  map_x_min,  map_y_nun.  map_x_max.  map_y_max; 
public: 

n»ap_crxO  1): 
map_crx(map  mapl); 


void  set_value(map  mapl); 
int  insidejK vector  pi); 

int  map_crossing( vector  pi,  vector  p2,  vector&  start,  vector^  end); 
int  map_inter8ect(vector  pi,  vector  p2,  vectorA  start,  vector&  end); 
I: 


#endifMAP_CRX_H 
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FILENAME . plane.h 


AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1W3 

DESCRIPTION . :  Headrr  file  for  description  of  plane  class  and  its  functions. 


fifhdef  PLANE.H 
#define  PLANE.H 


#include  “vector.h” 
#include  “UneJt’' 


class  plane  ( 

vector  unit.nomal;  /*unit  normal  vector  */ 
double  distance;  f*  -distance  from  origin  */ 
public: 
planeO  (I  ; 

plane< vector  normal,  double  dist)  ( 
uniLnormal  >  normal.normalizeO: 
distance*  dist; 

I 

/*  If  line  is  parallel  to  a  plane,  then  lelOO  is  returned  V 

/*  If  line  is  parallel  to  a  plane  attd  on  the  plane,  this  routine  also  return  lelOO.  *! 

/*  If  start  of  a  line  touches  a  plane  without  being  parallel  to  the  plane,  then  it  will  return  zero  distance  */ 

double  plane.distance(vector  velocity,  vector  position); 

int  plane.intosectionfline  line,  vectar&  pt,  double&  distance); 

int  plane.line.cross(line  linel,  vector^  pt,  doubled:  distance); 


#endif 
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Fn.ENAME . :  n)ut_cntd.h 

AUTHOR . :  Dr.  S©-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Header  file  which  contains  the  routing  information  for  use  of  all  routing  source 


#ifhdefROUT_CMD_H 
#define  ROUT_CMD_H 

♦define  ROITTCR.BUF.SIZE  1024 

/*  Netwoik  definition  (actually  tree) 
master 

routeiO  -  workers 
routerlfouterZ 

routerl  1  routerll  router^l  router22  iouter23 

one  node  can  have  up  to  three  descendant  nodes, 
one  node  can  have  many  workers. 

•/ 

/• 

ID  number  for  routerl2  is  1001 
ID  number  for  routerl23  is  111001 

•/ 

r 

Task  number 

start  from  0!II!  (cf.  routers.  0. 1.2. 11.12.13. 21.22  ..) 

For  example,  fint  task  connected  router  12  is  taskl20  and 
NTS  field  in  send.map  is  0. 

•/ 

/• 

Pon  Numbers 
0:  upper 

\23  lower  (may  none  conrtected) 

4 ..  ;  utdcs 

*/ 
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/*  ‘!.it  message  fonnat  (cimM  or  1)  */ 

/*  0  cmd  #_of_tasks  #_of^lower_iouter  destination  cunent_kvel*/ 
n  3  4  4  16  4  bits*/ 

ro  CMD  rm  low  dst  cll  */ 

r  send.map  message  fonnat  (cmd>2)  */ 

/•O  cmd  task#  ?7?  destination  ???*/ 
r  1  2  4  4  16  4  bits*/ 

ro  CMD  NTS  777  DST  777*/ 
r  map-size*/ 
r  32  */ 

/*  map  data*/ 
r  variable  length  */ 

/*  bcast.req  message  fonnat  (cmd-3)  */ 

/•  0  cmd  size  777*/ 

/*  1  3  8  20 bits*/ 

/*  0  CMD  BCS  777  •/ 
r  BCS  size  message  follows  */ 

/*  terminate  message  formal  (cmd»4)  */ 

/*  0  cmd  777777  */ 

/•I  3  28bits*/ 

ro  CMD  777  */ 

/*  cmd  0 :  init  (stan) 

1 :  tenrunaie  init 
2 :  send  map 

3  :  beast  reqest  (los  request,  automatically  replied  by  workers) 

4 ;  laminate 

*/ 

#defineSTART_INITO 
#define  TERMINATE.INIT  1 
iderine  SEND.MAP  2 
gdcfine  BCAST.REQ  3 
idefine  TERMINATE  4 


#derine  ROUTE.CMD.MASK  0x70000000 
gdefine  ROUTE.NTS.MASK  OxOFOOOOOO 
♦define  ROUTE_LOW.MASK  OxOOFOOOOO 
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#deflneROUTE_DST_MASK  OxOOOFFFFO 
#defincROUre>CLL_MASK  OxOOOOOOOF 
#<kfincROirre_BCS_MASK  (hOFFOOOOO 


#<lcfinc  ROiniE^CMD.SHIFT  0x10000000 
#define  ROUTE.NTS.SHIFT  0x01000000 
♦define  ROUTC.LOW.SHIFT  0x00100000 
♦define  ROUTB.DST.SHIFT  0x00000010 
♦define  ROUTE_CLL_SHIFT  0x00000001 
♦define  ROUTE.BCS.SHIFT  Or'YllOOOOO 

/*  Use  divides  and  multiplies  instead  of  shifts  for  q)eed  */ 

♦define  ROUTE.UNPACK.CMEKn)  ((n  St  ROUTE.CMD.MASK)  /  ROUTC.CMD.SHDT) 
♦define  ROUTE,UNPACK_NTS(n)  ((n  St  ROUTE_NTS_MASK)  /  ROUTE,NTS_SHIFD 
♦define  ROUTE_UNPACK_LOW(n)  ((n  &  ROUTC_LOW_MASK)  /  ROUTE.LOW_SHIFT) 
♦define  ROUT1E_UNPACK_DST(n)  ((n  &  ROUTE_DST_MASK)  /  ROUTE.DST.SHIFD 
♦define  ROUTE_UNPACieCLL(n)  ((n  &  ROUTE_Cli_MASK)  /  ROUTE.CLL.SHIFT) 
♦define  ROUre_UNPACK_BCS(n)  ((n  &  ROUTE.BCS.MASK)  /  ROUTE_BCS_SHIFT) 


♦define  ROUTE_PACK_CMD(p,n)  p-(p  &  (-ROUTE_CMD_MASK))  I  (n*ROUTE_CMD_SHIFT) 
♦define  ROUTE_PACKJJTS(p.n)  p^p  St  (-ROUTE_NTS_MASK))  I  (n*ROUTE_NTS_SHIFT) 
♦define  ROUTE_PACK_LOW(p.n)  p-(p  &  (-ROirre.LOW.MASK))  I  (n^ROUTE.LOW.SHTFT) 
♦define  ROUTE_PACIC^DST(p.n)  p-(p  &  (-ROUTE.DST.MASK))  I  (n*ROUTE_DST_SHIFT) 
♦define  ROUTE_PACK_CLL(p.n)  p^p  St  (-ROUTE.CLL.MASK))  I  (n-ROUTE.CLL.SHDT) 
♦define  ROUTE_PACK_BCS(p.n)  pKp  St  (-ROUTE.BCS.MASK))  I  (n*ROUTE_BCS_SHlFT) 

♦endifROUT_CMD_H 
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FILENAME . :  router.h 

AUTHOR . :  Dr.  Se>Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . ;  Sqxember  1993 

DESGUPTION . :  Header  file  for  the  source  code  which  performs  the  routing  for  the  current 

topology  of  transputer  network. 

#ifhdefROUTER.H 
#definc  ROUTER^H 

tinclude  <chan.h> 
fittclude  ‘Yout_cmd.h" 

/• 

Port  Numbers 
0:  upper 

1 .23 :  lower  (may  none  connected) 

4 .. :  taxkfc 

•/ 

#define  UPPER.PORT  0 

#dcfine  FIRST J-OWER_PORT_NUMBER  I 

#dcrine  FIRST_TASK_PORT_NUMBER  4 

class  router  { 
int  router.id; 
int  level; 

int  hasJ*:af_node _p; 

int  lastjowcr jxxt_numbcr, 

int  tast_task_port_number. 

CHAN  ••injxwts: 
int  ins; 

CHAN  **out_poits; 
int  outs; 
int  message; 

char  router_buf[ROUTER_BUF_SIZEJ; 


public: 

routeifCHAN  •in_ports[)  jnt  ins,  CHAN  *out_ports(l4nt  outs); 
void  init(void); 
int  cmd_type(void); 
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void  send_inap(void): 
void  bcast_req(void); 
void  tenninaiB(void); 
void  answef(void); 

void  trans_inap<int  port_nuinberint  map.size); 

); 

#cndifROUTER.H 
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. . 

FILENAME . :  routef2.b 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Header  file  for  the  source  code  which  performs  routiog  between  tran^ters. 

. . . . . . * . I 


#ifiidefROUTER2.H 
«defiiie  ROUTBR2_H 

tiDcIode  <chui.h> 

#iDclude  “n>ut_cfn<Lh” 

class  router2  ( 

CHAN  **10^)008: 
int  iiu: 

CHAN  ♦•oot_pons: 
int  outs; 

public; 

rootei2()(|; 

routef2(CHAN  *iit_poit8[]4nt  ins,  CHAN  *out_poit3[]4nt  outs); 

void  router_init(iiM  dts,  int  low,  int  nts); 

void  router_init_done(void); 

void  seod(int  dst,  int  nts,  int  size,  char*  buf); 

void  bcast(int  size,  char*  buf); 

lot  UsterKvoid); 

void  leiminate(void); 

I; 


#eiidifROUTER2_H 
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- - - - - 

FILENAME . :  roumS.h 

AUTHOR . :  Dr.  Sc-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . ;  September  1993 

DESCRIPTION . ;  Header  file  for  the  source  code  which  performs  routing  in  a  transputer. 

. . . 


#ifndefROUTER3_H 
♦define  ROUTER3_H 

♦include  <chan.h> 

♦include  “rout_cmd.h" 

♦define  SEND  SEND.MAP 
♦define  BCAST  BCAST.REQ 
/♦TERMINATE  comes  from  “rout_cmd.h”  •/ 

class  routers  ( 

CHAN  ♦•in.pons; 
int  ins; 

CHAN  ••out_potts; 
int  outs; 
int  message; 
int  retum.value; 

public: 

iDuter3(CHAN  •injxwtslQ.int  insl,  CHAN  •outjwrtslOjnt  outsl); 
int  cmd_type<iiit&  size);  /*  return  type  as  well  as  size  of  data  */ 
void  receive(int  size,  char*  buO: 
void  answer(int  value); 
void  terminatefvoiJ); 

1: 


♦en(UfROUTER3_H 
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FILENAME . :sJo6.h 

ALTHOR . ;  Dr.  Sc-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  Header  file  for  the  source  code  which  performs  LOS  calculations  between  two 


#ifhdefS_LOS_H 

#defineS_LOS_H 


#include  “vector.h” 

#include  “map.h” 

class  sjos  ( 

public: 

sJosOII 

/*  Perfomts  LOS  calculations.  */ 
ini  do_s_lo6(vector  start,  vector  goal.  map&  mapl); 
); 


#endifS_LOS_H 
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FILENAME . 

AUTHOR . 

DATE . 

DESCRIPTION 


:  tr.comm.h 

:  Dr.  Se-Hung  KWAK  &  Ccm  Ali  DUNDAR 
:  September  1993 

:  Header  file  for  the  source  code  which  performs  the  communication  between 
SUN  station  and  transputers. 


#ifhdefTR_COMM_H 

#defineTR.COMM_H 


finclude  <chan.h> 
#include  ‘Toutet2.h'’ 


const  int  ROUTER.INTT.S  ■  1; 
const  int  SEND.S  ■  2; 
const  int  BCAST_S  »  3; 
const  int  LISTEN.S  «  4; 
const  int  TERMINATE_S  ■  5; 

class  tr.comm  ( 
iDuter2  router2a; 

CHAN  **inj)oits; 
int  ins; 

CHAN  •*out_ports: 
int  outs: 


public: 

tr_comm(CHAN  •injxtrtsD.  int  ins,  CHAN  •outjxwtsi).  int  outs): 

int  cmd_typcO:  /*  Return  type  •/ 

void  router_init(void); 
void  sendfvoid); 
void  bcast<void); 
void  listen(void): 
void  terminatefvoid); 


#endifTR,COMM.H 
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FILENAME . :  vector.h 

AUTHOR . :  Dr.  Se-H«ng  KWAK  &  Cem  Ali  DUNDAR 

DATE . . . :  September  1993 

DESGUPnON . :  Header  file  for  the  description  of  the  vector  class  and  vector  class  opei  oions. 

. . . . . 

iifndef  VECTOR.H 
#deancVECrOR_H 

class  vector  ( 
double  x,y^; 
public: 
vectorO; 

vector(double  xl,  double  y  1,  double  zl); 

dot'ble  get.xO  {return  x;); 
double  get  I  retuni  y; ) ; 
double  get.zO  {retuni  z;); 

friend  int  operator»(vector  v  1 ,  vector  v2): 
friend  vector  operaior-K vector  vl,  vector  v2); 
friend  vector  operalor-fvector  vl,  vector  v2); 
friend  vector  operator*(double  a.  vector  vl); 
double  doqxod(  vector  v  1 ); 
double  magnitude(void); 
vector  normalizefvoid); 

I; 

#endif  vector  H 
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FILENAME . ;  Une.q>p 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . ;  This  source  code  is  for  a  line  equation. 

#inclu(le  "line.h” 

lino::Une(vector  pci ,  vector  dir) 

{ Stan  ■  ptl;  direction  «  dir, ) 
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FILENAME  . ;  mapxpp 

AUTHOR . . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  Sqxember  1993 

DESCRIPTION . ;  This  source  code  defines  the  map  class  functions. 


#include  "map.h” 
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inap::mapO  /*  Constructor  */ 

I 

p  ■  new  nuq)_rep; 

p->stan_x  •  0;  p->start_y  ■  0:  p->si2e_x  ■  0;  p->8ize_y  ■  0; 
p->grid_suc  ■  0.0; 
p.>daia  ■  0;  //  null  pointer 

) 


inap::map(int  start.xjmt  start _y,int  size.xjnt  size_y .double  giid.size jnt*  data)  /*  Constructor  */ 


p  ■  new  inap_rq): 

p->8tan_x  ■  stait.x:  p->8tan_y  ■  8tait_y; 
p->size_x  ■  fize.x;  p->size_y  ■  size_y. 
p->grid_8tte  ■  gridjsize; 
p.>daia  data; 

I 

map::inap(const  m^>&  map)  /*  Copy  constructor  *1 

I 

map.p<>refs4~(-: 
p  ■  map.p; 

I 

map&  map::operBtorB(con8t  map&  map)  /*  Assignment  operator  */ 

I 

map.p->refsM-; 
if  (-p->ref8  ■■  0)  I 
deleteU  p->data; 
delete  p; 


p  ■  inap.p; 
return  *thi8; 

I 
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map::~fnapO  /*  Dcsmictor  •/ 

I 

if  (-(p->refs) "  0)  { 
ddeteQ  ihxlau: 
delete  p; 

} 

) 

vector  inap::iojnap_cootd(vecior  loc) 

{ 

vector  m^_ofFset(((double)p>>stan:_x)*p->gnd_size, 
((doubIe)p->stan_y)*p>>grid_size,0): 

vector  loc_wit_inap  -  loc  -  map„offset; 
letum  (loc.wrt jnap); 

I 

ini  map::higher_than(veclor&  loc) 

{ 

int  grid.x  ■  (int)  ((loc.gct_x0  -  p->start_x*p->grid_8ize)^>grid_sire); 
int  grid_y  ■  (int)  ((Ioc.get_y0  *  p->«an_y*p->grid_8ize)^>grid_size): 
fetum(p*>daialgrid_y*p->8iie_x+grid_x)  >  Ioc.get_z0): 

) 


int  map::ternun_height(int&  gridjt,  ini&  grid_y) 
I 

return  map_post(grid_x,gnd_y); 

I 

int  map::!nap_p08t(int  grid.x,  int  grid_y) 

I 

int  index; 

index  ■  p->gize_x*grid_y  +  grid_x; 
return  p->data(index]; 

) 
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FILENAME . :  map^cnxpp 

AUTHOR . :  Dr.  Sc-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESGUPTION . :  This  source  file  checks  whether  LOS  passes  through  a  map  contained  in  a 


transputer  or  not 


#include  “map.crsh" 


7 


map_crx;:map_cn(map  mapl) 

I 

map..x_min  « (k)uble(mapl.get_siart_xO)  *  mapl.get_grid_sizeO: 
inap_y_min  «  double(inapl.get_start^O)  *  mapl.get_grid_sizeO; 
map_x_ma3t  ■  map_x_min  double(mapl.get_si2e_x0)  •  mapl.get_grid_sizeO: 
map_y_max  ■  map_y_min  +  double(mapl.get_si2e_y0)  •  mapl.gei_grid_size(): 
I 


void  map_crx;;set_value<map  mapl) 

I 

map_x_min  ■  double(mapl.get_8tart_x0)  *  mapl.get_grid_sizcO: 

»»>ap_y_min  ■  double<mapl.get_slart_y0)  *  mapl.get_grid_sueO; 
map_x_max  ■  map_x_inin  +  double(mapl.get_size_x0)  •  mapl.get_grid_sizeO: 
map_y_max  ■  map_y_inin  double(mapl.get_8ize_y0)  *  mapl.get_grid_si2e0; 

) 

int  map_crx::inside_p(vector  pt) 

I 

r  inside_p  includes  boundary  too.  */ 
double  delta  ■  O.OOOOS; 

if  ((pt.gf!t_xO  >  map_x_min-delia)  &.&  (pt.get_xO  <  map_x_max4dclta)  && 
(pLget_yO  >  map_y_min-delu)  &.&.  (pcget_yO  <  map_y_max+delta)) 
retum(l); 
else 

reiurn(O); 

I 
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int  inap_crx::inap.crossing(vector  pi,  vector  p2, 
vector^  Stan,  vector^  end) 

I 

vector  pxl,px2; 

if  ((inside_p(pl))&&(insidejKp2)))  ( 
startapl; 
end  ■p2; 
reoint  1;) 
else  ( 

if  (inside_p(pl))  | 
inap_intefsect(p  1 4>2,px  1 4>s2); 

Stan  ■  pi; 
endapxl; 
return  1;) 

else  if  (inside _p(p2))  ( 

Stan  ■  p2; 

map.intersect(p  1  j>24)x  1 4>x2); 

endapxl; 

return  1;) 

else  I 

if  (inap_inteiseci(pl4>2,pxl  j>x2))  ( 
stanxpxl; 
endapx2; 
return  1;| 
else 

return  0; 

I 

I 

1 


int  map_crx::map_iniersect(vecior  pi,  vector  p2,  vecior&  pxl,  vecior&  px2) 

{ 

r  This  routine  returns  two  intersection  pts;  px  I ,  px2  */ 

/*  If  they  ate  identical,  then  pxl  ■  px2  */ 

/*  If  3D  pts,  pi  &  p2.  <ve  given,  then  pxl  and  px2  are  3D  pis  */ 

•ector  pt,  pl8(2); 
double  dist: 
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vector  x_nonnal(  1,0,0),  y_nonn«I(0,1.0); 


plane  pIane_xl(x_nonnal,  -1.0*map_x_min); 
plane  plane_x2(x_nonnal,  •1.0*map_x_inax); 
plane  planejfl(y_nonnal,  •1.0*map_y_inin); 
plane  planc_y2(y_nonnal.  -1.0*nuq)_y_inax); 
vector  delta  Bp2- pi: 
line  linel(pl4>2-pl): 

int  num  ■  0; 

r  There  are  two  distinct  pts  •/ 
if  (plane_xl.plane_Iine_cross(linel,  pt,  dist)) 
if  (insidejKpt))  { 
ptslnuin]  ■  pt; 
nunvM-: ) 

if  (plane_x2.planc_linc_cross(linel,  pt,  dist)) 
if  ((inside_p(pt)  &&  num  AA.  !(pts(num-ll»«pt))  II  inside_p(pt))  { 
pts[num]  ■  pt; 
num4^;  I 

if  (pIane_yl.plane_line_cn)6S(linel, pt,  dist))  ( 
if  ((in5ide_p(p0  AA  num  AA  !(pts[num-l]«-pt))  II  inside j)(pt))  { 
pts(num]  ■  pt: 
num-M-: } 

I 

if  (plane_y2.pIaneJinc_cro«8(linel,  pt,  dist)) 
if  ((inside_p(pt)  AA  num  StA  !(pts(num-l]B«pt))  H  insidc_p(pt))  { 
pt8[num]  ■  pt; 
num-H-; ) 
if  (num  ■■  0) 
return  0; 

else  if  (numBsl)! 
pxl  ■  pt8[0): 
px2  ■  pts(0]; 
reuim  1:1 
else  I 

pxl  -  pts(O): 
px2-pts(I]; 
return  1:| 

) 
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FILENAME . :  pUne.q^ 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . ;  This  source  code  is  for  plane  equations  and  functions. 


#iiKlude  “plane.h” 
tinclude  “vector.h’' 

#iiKlude  <math.h> 

double  plane:;plane_distance  (vector  velocity,  vector  position) 

I 

r  plane  (X-Q)N«0,  line  X«P+tA. 

t  ■  (Q-P)N/(AN).  if  A  is  normalized  then  t  is  signed  distance. 

If  t  is  infuiitivc,  then  plane-distance  returns  NULL. 

otherwise,  plane-distance  returns  distance.  */ 

vector  A  «  velocity .normalizeO; 

vector  N  ■  unit_nonnal; 

double  dis  «•  -1.0  *  distance; 

vector  Q  ■  dis  *  N; 

vector  Q_P  *  Q  -  position; 

double  AN  ■  A.dotprod(N); 

double  numerator  ■  Q_P.dotptod(N); 

if(fabs(AN)<lE-100) 

retum(lE100); 

else 

rctum(numerator/AN); 


int  plane;:plane_intersection(line  Unel,  vector&  pu  doubled  distance) 

I 

vector  velocity  b  linel.get.directionO.normalizeO: 
distance  m  (*this).plane_di8tance( velocity,  linel.get.startO); 
if  (distance  <  IE  100)  ( 
pt  a  linel  .get_startO  *  distance  *  velocity; 
return  1;| 
else 

return  0; 
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int  plafie::p)ane«Une.cioss(line  linel.  vectorA  pt,  doublcA  distance) 

< 

vector  velocity  *  linel.get_diiection0.nonnaUzeO; 
distance  « (*this).plane_distance(velocity,  linel. get.stanQ); 
if  ((distance  >-  0)  StSc.  (distance  <  linel.get.diiectionO  inagnitudeO))  ( 
pt  ■  linel. get.stanO  distance  *  velocity: 
return  1;) 
else 

return  0; 

) 
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FILENAME . 

AUTHOR . 

DATE . 

DESCRIPTION 


:  roucer.qip 

:  Dr.  Se-Hung  lO'^AK  &  Cem  Ali  DUNDAR 
:  Seprember  I9s 

:  This  is  the  main  routing  source  code.  It  handles  routing  for  the  current  topology 
of  transputer  network. 

. . . 


#include  'Youter.h” 


#include  <a]t.h> 


iinclude  <chan.h> 


router:router(CHAN  *in_portslO.»nt  insl,  CHAN  *outjx)itsl[]4ntoutsl) 

{ 

inj)orts«  in_pottsl: 
ins  ■  insl; 

out_j)orts  »  out_portsl; 
outs*outsl; 

1 


int  next_address(int  destination,  int  current.level) 

( 

retum((destination  » (curtcntjevel  *  2))  &  0x00000003); 

I 


void  routen:init(void) 

{ 

/*  message  format  •/ 

f*  0  cmd  #  .of.iasks  #_of_lower_rouler  destination  cuiTeiit_kvel*/ 
r  1  344  164bits  •/ 
r  0  CMD  NTS  LOW  DSTCLL  •/ 

r  cmd  1 :  init  (start) 

2 ;  terminate  init 

V 

for(;;){ 
int  message: 

chan_in_woixl(4messagc.in_ports(0)); 


/*  Checks  whether  to  terminate  init  routine. 
This  is  detected  by  the  first  node.  */ 
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if  (ROUTE_UNPACK^CMD(incssage)  —  TCRKONATE.INIT)  { 
foe  (ini  i-FIRST.LOWER^PORT^NUMBER:  i<«lasi_lowerj)ort_nuinber.  i++) 
chan_out_word(iness«ge.outj>ofts[i]); 
break; 

)  /*  If  there  is  no  lower  routers,  then  it  automatically  uoes  not 
send  anything.  */ 

int  destination  ■  ROUTE_lJNPACK^nST(message); 
ini  cuirent_level  ■  ROUTE_UNPACK^CLLfmcssagc); 
int  next.chan  *  ncxt_address(destinalion,  current_level); 

if  (!next_chan)  |  /•  This  is  the  destination.  •/ 

router_id  »  destination;  I*  Destination  is  ID.  •/ 
level  ■  cuiTcnt^level; 

int  nuni_of_lower_roulefs  ■  ROlJTE_UNPACK_LOW(messagc); 
last_lower_port_numbcr  »  num_of_lower_routers  +  FIRST_LOWER_PORT_NUMBER-l; 
r  0, 1..  num_of_lower_rouicrs.  task_poits....  •/ 
int  nuni_of_tasks  ■  ROUTE_UNPACK_NTS(message); 
last_task_pott_number  ■  num_of_iasks  +  FIRST_TASK_PORT_NUMBER- 1 ; 
if  (num_of_lower.  .routers !»  0) 
has_leaf_node_p  ■  1; 
else 

has_leaf_node_p  ■  0; 

I 

else  I 

message4-f;  /•  Increments  curtentjevcl  counter.  */ 
chan_oul_word(message.  out_pons[next_chan]); 

I 

1 

I 

int  router:cmd_type(void) 

I 

chan_in_word(&message,in_pOTts(0]); 

retiim(ROUTE_UNPACK_CMD(message)); 

) 


void  router:trans_map(int  port_number,  int  map_size) 

I 

chan_out_word(message.out_ponslport_numberl);  /•  Sends  header  first.  */ 
int  num_of_packets  ■  fnap_size  /  ROUTER_BUF_SIZE  +  1; 
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int  Ust_packet_size  ■  map.size  %  R0UTER_BUF_SI2E: 
chan_out_wO(d(inap_size^t_poits[pon_nuinber]);  /*  Sends  map  size.  */ 
while  (niim_of_packets>0)  ( 
if  (num_of_packetS"l) 
if  (last  j»cket_size  >  0)  ( 

chan_in_fnessage(last_packet_size/outer.buf,injx}its[0]); 
chan_out_message(Iast_packet_sizejouter_buf,out_p(»ts[poit_number]);) 
else  (/*  nothing  to  transfer  */) 
else  I 

chan_in_message(ROUTER_BUF_SlZEjouter_buf4njx>rts[03): 

chan_out_message(ROUTER_BUF_SIZEjouter_buf,out_poits[port_number]): 

I 

num_of_packets*': 

) 

) 

void  router:send_map(void) 

I 

int  m^.size: 

chan_in_woid(&map_size4nj)oits(0]); 

int  destination  ■  ROUTE_UNPACK_DST(message); 

/*  Two  cases:  This  node’s  task  or  pass  down  */ 
int  next.chan  ■  next_address(destinaiion,  level); 

if  (!next_chan)  (  f*  This  is  the  destination.  */ 

/•  Gets  task  number.  •/ 

int  task_port_number  ■  ROUTE_UNPACK_NTS(message>+FIRST_TASK_PORT_NUMBER; 
trans_map(taskjw(t_number^ap_size);  | 
else 

trans_map(nexi_chan^ap.size); 

I 

void  fouten:bcast_req(void) 

I 

int  size  «  ROUTE_UNPACK_BCS(message); 
chan_in_message<size4Duter_buf,in_poits[0]); 

for  (int  i«FIRST_l.OWER_PORTj*fUMBER;  i<*slast_lower_port_number:  i++)  ( 
chan_out_word(message.out_pons[i]);  /•  Sends  down  •/ 
chan_out_message(size/ouier_buf,oui_ports(i]); 

I 
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for(i«FIRST_TASK„PORT_NUMBER;  i<-Iast_ttskj)on_number,  i^)  { 
chai\_ou^word(ine8sage^t_ports[i]):  /*  Sends  down.  •/ 

chnn_ouL>nessage<size^iBr_buf.out_poTts[i]); 

) 

) 

void  router  :answer( void) 

{ 

int  sum  ■  0;  T  Should  be  zero,  now  just  testing  mode.  */ 
int  )ower_sum,  task^sumaO; 
int  chan; 

for  (int  i«FIRST_TASK_PORT_NUMBER;  i<-Iast_task_poft_number.i++)  { 
chan  »  alt_wait_vec(ins,  in_ports); 
chan_in_word(&task_sum,in_ports[chan]); 
sum  ■  sum  *  task_sum: 

1 

for  0»FIPST_LOWER_PORT_NUMBER;  i<»last_k)werj)ort_number.  i++)  | 
chan  »  alt_wait_vec(ins,  in_ports); 
chan_in_word(&lower_sum,in_poits(chan)); 
sum  ■  sum  +  lower.sum; 

} 

chan_out_word(sum.out_ports(0)): 

I 

void  router.:terminate<void) 

{ 

for  (int  i«FIRST_LOWER_PORT_NUMBER;  i<»lastJower_p(*t_number.  i++) 
chan_out_word(mcssage,out_pofUli)); 

for  (i«FIRST_TASK_PORT_NUMBER;  i<«last_tasic_pon_number,  i-M-) 
chan_out_word(inessage.out_p(Mts(i)); 

) 
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FILENAME . :  routencpp 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  This  soivce  code  performs  routing  for  transputers. 


#include  <chan.h> 

#include  "router.h" 

void  mainCuit  argc,  char  *argvQ,  char  *envp[l. 

CHAN  *iiijx)rtsD,  int  ins.  CHAN  *out_portsQ.  int  outs) 

I 

int  exit.flag  ■  0; 

router  routerl(in_potts,ins,out_ports,outs); 
router  l.initO: 

while  (leut_Qag) 
switch  (routerlxmd.typcO)  < 
caseSEND.MAP: 
router  1  jend.mapO; 
break: 

case  BCAST.REQ : 
router  I  .bcast_ieqO; 
router  ljutswerO; 
break; 

case  TEilhilNATE : 
router  1  .terminateO: 
exit_flag  ■  I; 
break; 
default: 

/•error*/ 

break; 


) 
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FILENAME . :  nMMt2.cpp 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . ;  September  1993 

DESCRIPTION . :  This  source  code  petfonns  routing  between  tnuispuieis. 


#include  *lT)uter2.h** 

#include  <io8tream.h> 

const  int  OUT_PORT_NUM  ■2; 
const  int  IN_PORT_NUM  ■  2; 

routei2::router2(CHAN  •in_poitsl[]4nt  insl,  CHAN  •outjxwtslQ.int  ouisl) 

1 

in_partSB  in_portsl: 
ins  a  insl: 

out_port8  ■  out_portsl; 
outsaoutsl; 

) 

int  conveft_to_dst(int  destination) 

I 

r  Destination  address  does  not  contain  zero.  */ 
intdstaO: 

int  digit  ■  destination  %  10; 
destination  ■  destination  / 10; 
while  (digit)  ( 
dst  ■  (dst «  2)  I  digit; 
digit  ■  destination  %  10; 
destination  «  destination  / 10; 

) 

return  dst; 

I 

void  rouier2;:router_inii(int  destination,  int  low,  int  nts) 

I 

int  message  ■  O, 

int  cll  ■  0;  /*  Current  level  number  */ 

ROUrE_PACK_CMD(ines8age,START_INrD; 

ROUTE_PACK_NTS(nte8sagej>ts); 

ROUTE.PACK_LOW(me88age,low); 
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ROUTE_fAClC_DST(messa8Bvconvtn.to_dst(destination)); 

ROUTE^AC]C^CLL(inessage^Il); 

chan.out.woid(iTtessagexMiLpoft8[OUT_PORT_NUM]): 


void  n>uier2;;router_init_done(void) 
int  menage  ■(); 

ROin^ACieCMD(menage.TERMINATEJNIT); 

ROin*EJ»ACKJLOW(me88age^); 

chan_out_word(nienagewtj>onslOUT_PORT_NlJM]): 

) 

void  router2;;tenninaie<void) 

I 

int  menage  ■  0; 

ROUTE J>ACK_CMD(me88age,'reRMINATE); 
chan_oui_word(meangex)ul_poit8{OUT_PORT_NUM]); 

) 

void  ioutei2::aend(int  destination,  int  nts,  int  size,  cha/^  buf) 
int  message  ■  0; 

ROUTE.  J»ACK_CMD(message,  SEND_MAP); 
ROUTEJ*ACK_NTS(mesaage,  nts); 

ROUTEJPACK_DST(message,  conven_to_dst(destination)): 

/•Sends  “header”*/ 

chan_out_word(fnessage,outj>orts(OUT_PORT_NUMl); 

/•Sends  “size"*/ 

chan_out„woid(slze,outj)Ofts(OUT_PORT_NUMl); 
chat*  bp  ■  buf; 

int  num.of .packets  <•  size  /  ROUTER.BUF.SIZE  *  1; 
int  lastjpackeLsize  ■  size  %  ROUTER.BUF.SIZE; 
while  (num_ofj>ackets>0)  ( 
if  (num.ofjtacketsul) 
if  (last  j>acket.jize  >  0)  | 

chan_out_message(last  j>ackei_size,bp,out  j)OTt8(OUT_PORT J^UM]): ) 
else  I  /•  Nothing  to  send  •/ ) 
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else  { 

chan_oiii_me8Mi|e(ROUTER_BUF_SEZE,bp,out_port»lOin‘.,,PORT_NUM]): 
bp  R01JTER_BUF.SIZE; 

} 

nuin_of jHckets*  ■: 


void  iouter2::bc&st(int  me,  char*  buO 

( 

int  message  ■  0; 

ROUTEJ»ACK_CMD(n>es8ageJCAST_REQ); 

ROUTE J»ACK_BCS(measage4i2e): 

chan_out_word(mes8age4)«Lpoit8[OUTJPORTJ'IUMl); 

chan_ouLn>easago(8ize,buf>)ut_poitstOUT.^RTJ^UMl); 

) 

int  router2::listen(void) 

I 

im  message; 

chan_in_word(&me8sage,  in_poits[INJPORT_NUM]); 
return  message: 

I 


144 


FILENAME . :  ioulBi3.q>p 

AUTHOR . :  Dr.  Se-Hiing  KWAK  &  Cem  AU  DUNDAR 

DATE . :  September  1993 

DESGUPTION . :  This  source  code  performs  routing  for  workers. 


#include  ‘YouterS.h” 

router3:30ulBr3(CHAN  *in_pottslQ4nt  insl,  CHAN  *out_portslQ,int  outsl) 

{ 

injxxtSB  in_portsl: 
ins*  insl; 

out_port8  ■  out_port8l; 
outs  ■  outsl: 

I 

int  rouier3::cind_type(int&  size) 

I 

chanJfLwonK&message,in_poits(0]); 

int  cmd  ■  ROUTE_UNPACK_CMD(incs8age); 

if  (cmd  ■■  SEND) 

chan_in_wotd(&stze.in_ports(0]); 

else 

size  ■  ROUTE_UNPACK_BCS(me8sage); 
retum(cmd); 

I 
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void  router3::receive<int  size,  char*  buO 
char*  bp  ■  buf; 

int  num.of jMckeis  >  size  /  ROUTER_BUF_SIZE  *  1; 
int  last_packet_size  ■  size  %  ROUTER.BUF.SIZE; 

while  (num_of_packets>0)  ( 
if  (num.ofjncketsaal) 
if  (last_packeLsize  >  0)  ( 

chan_ui_ine8sage(last_packet_size,bp  jn  jxxtsfO]); ) 
else  I  f*  Nothing  to  send  */  | 
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olio  { 

ch«uta_ine«8«(RCHnERJUFJlZE.bp.inj)om 

bp  +-  ROUTER^BUF.SEE; 

) 

num_of_packete--: 

) 

) 

void  router3::answei<int  value) 

I 

chan_out_word(value,oui_pottstO)); 

) 


void  router3;:tenninate(void)  { ) 
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— - - - 

FILENAME . :  s_lo8.cpp 

AUrH(» . :  Dr.  Se-Hung  KWAK  &  Can  AU  DUNDAR 

DATE . :  Sepcember  1993 


DESCRIPTION :  This  source  code  performs  LOS  calculations  baween  two  points  in  the  map  area. 

Returns  0  if  LOS  exists,  returns  1  otherwise. 


#include  <math.h> 
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iinclude  “sjos-h" 
tinclude  “map.h” 


int  sJos;:do_s_los( vector  start,  vector  goal.  map&  mapl) 


int  siBpsJ; 

vector  del  ^  goal<start; 
int  deLxi.  del^; 

del.xi  ■>  (int)  (fabs(del.get_xO)/  mapl.get_grid_sizeO): 
del_yi  ■  (int)  (fabs(del.get_y0)/tnapl-get_grid_si2e0): 
stqts  ■  (deLxi  >  dd_yi)  ?  del_*i :  dcl_yi: 


/*  Steps  -f  1  is  necessary .  because  without  adding  1 ,  the  last  goal  point  is  not  tested.  */ 
vector  delta_step  ■  (1.0/steps)*del; 
vector  checkjoc  ■  start; 


for  (W);i<steps:i++)| 
if  (mapl.higher_than(checkJoc)) 
return  1; 

check.loc  ■  check.loc  +  delta_stq); 

1 

return  0; 


) 
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FILENAME . :  tr.conun.qip 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Can  Ali  DUNDAR 

DATE . :  Sepiemba  1993 

DESCRIPTION . :  This  source  code  handles  the  communication  between  transputers. 


tinclude  “tr_conun.h" 
tinclude  <chan.h> 

#include  <iostream.h> 

#include  “los^com.h” 

const  int  IN_PORT_NUM»4; 
const  int  OUT_PORT_NUM»4; 

tr_comm;:tr_comm(CHAN  •injwrtsin,  int  insl,  CHAN  *out_portslO.  int  ouisl) 

I 

routet2a  ■  routcrKinjxMlsl,  insl.  out.portsl,  outsl); 
in_pansB  in_poftsl: 
ins  >  insl; 

out_poits  ■  oiitjportsl; 
outs  •outsl; 

I 

int  tr_comm::cmd_typeO 

I 

int  cmd; 

chanJn_word(4cmdinj)OTtsfIN_PORT_NUMl); 

letum(cmd); 

) 


void  U'_comm:;routa_init(void) 

{ 

int  num_trs; 

int  •«,  *unders.  •prs; 

chan_in_word(&nom_tr8jn4X)fts[IN_PORT_NUM]); 

trs  «  new  int[num_irs]; 
unders  •  new  int[num_tn]; 
prs  ■  new  int[num_trsl; 

int  size^num_tn*sizeof(int); 
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chaiv_iiv_inessagc(size.(char*)irijn_potts[IN_PORT_>IUM]): 

chan_in_nte8sage(size,(chai*)un(lerB4n_ports[IN_PORT..NUMl): 

chanJn_inessage(size,(char*)prs4n_portsnN_PORT_NUM]): 

for  (int  Wh  i<nuin_iis:  i++) 
rouiBr2a.iouter_iiut(tn(i],undei^[t]  .prsfi]); 

f*  Tenninaies  initializatioo.  */ 
fDuief2a.n>uter_init_doneO; 

I 

void  tr_coinm;:scnd(void) 

I 

int  dst; 

chan_in_word(&dst4n_pom[IN_PORT_NlJM]); 

intnts; 

chan_in_woid(&nts4n_ports[IN_PORT_NlJM]); 

int  size; 
char*  buf; 

chan_in_word(&si2C4nj)orts[lN_PORT_NUM]): 
buf  ■  new  chaifsize]; 

chan_in_ine8sage(8ue.buf4n_pott8lIN_PORT_NUM]); 
router2a.send(dst,  nts,  size,  buf ); 


void  ir_comm::bcast(void) 

I 

int  size: 

chan_in_word(&size4n_poits[IN_roRT_NUM)); 
char*  buf; 

buf  ■  new  char(size]; 

chan_in_inc8sage(size.buf4n_ports(IN_PORT_NUM]); 
CMD.INFO  •cnid_infop; 
cmdjnfop «» (CMD_INFO*)buf: 


149 


ioutef2jLbcasi(8ize,  buf): 

1 

void  tr.coinin::listen(void) 

{ 

nt  value  ■  iDuter2a.U8tenO; 

chan_out_wofd(value,outj)oits(OUT_PORT_NUMl): 

I 

void  tr_coinin::ierTninate(void) 

{ 

routef2a.tenninate0; 

) 
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FILENAME . ;  tr.commtcpp 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  This  source  code  handles  the  communication  between  SUN  and  transputers. 


#include  "tr.comm.h" 

#include  <iostream.h> 

void  mainCmt  argc,  char  *argvO,  char  *envp(], 

CHAN  •in.portsQ,  int  ins.  CHAN  •out_ports[].  int  outs) 

int  exit_flag  ■  0: 

tr^comm  tr_comml(in_ports,ins.out_ports.outs); 
while  (ieut.Qag) 
switch  (tr_comml.cmd_typeO)  I 
case  ROUTER_INIT_S: 
tr.comm  1  .router_initO; 
break; 

case  SEND.S: 
tr_comml.sendO; 
break; 

case  BCAST.S: 
tr.comml.bcastO; 
break; 

case  USTEN.S: 
tr_coiiunl.listen(); 
break; 

case  TERMINATE.S: 
tr_comm  1  .terminateO; 
exit.Qago  1; 
break; 

default:  f*  Error  •/ 
break; 

I 
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FILENAME . :  vector.qip 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  AU  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  This  source  code  defines  the  vector  class  operations. 


#include  "vector.h" 

#include  <math.h> 

vector :vectorO  {x»0.0;  y^.O;  za^.O;): 

vector:vector<double xl, double  yl, double zl)  (x*xl;  y«yl;  zszl;); 

int  (^)erator»(  vector  vl,  vector  v2) 

I 

retuTn((vl.x*»v2.x)  &&  (vl.y>*siv2.y)  &&  (vl.z«sv2.z)); 

I 

vector  operator-Kvector  vl.  vector  v2) 

I 

vectOT  v(vl.x+v2.x,  vl.y+vZy,  vl.z+v2.z); 
return  v; 

1 

vector  operator-fvector  vl ,  vector  v2) 


vector  v(vl.x-v2.x,  vl.y«v2.y.  vl.z-v2.z); 
return  v; 

) 

vector  operator*(double  a,  vector  vl) 

I 

vector  v(a*vl.x,  a*vl.y,  a*vl.z); 
return  v; 

1 

double  vector:dotprod(vector  v2)  I*  Dot  product  •/ 

I 

rtturn(ihis->x*v2.x  +  this->y*v2.y  +  this->z*v2.z); 

I 
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double  vector:inagnitude(void) 

ieturn(s<)tt((*this).doiiirod(*dus))); 

I 

vector  vector  :nonT)alize(void)  /*  Vector  nonnalizadon  */ 

i 

vector  result; 

double  mag  ■  (*thi8).inagiutude0: 

if(mag<lE-100)| 
results  ■  O.O, 
resulty  >  0.0; 
lesultzaO.O;) 
else  { 

lesult  ■  (l.OAnag)  •  (•this); 

) 

retunKresuh); 

) 
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FILENAME . :  fvoricerx^pp 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

DATE . :  September  1993 

DESCRIPTION . :  This  source  code  handles  the  communication  between  routers  and  workers, 

passes  all  information  to  workers  and  gets  the  result  which  they  found. 

#include  ‘YouterS.h" 
finciude  “los.com.h” 
tinclude  “s  Jos.h" 
finciude  “map_crx.h” 

int  num_cnt(int  n-  m,  int*  buf,  int  buf_size) 

I 

int  cnt «  0; 

for  (int  i»0;  i<buf_sizc;  i++) 
if  (buflil^num)  cnt-M-; 
return  cnt; 

1 


void  main(int  argc,  char  ‘argyn,  char  •envpf]. 

CHAN  •in _portsD.  int  ins,  CHAN  •outjxntsO,  int  outs) 


I 

/*  three  cases;  get.map 
get_teq  &  return  answer 
terminate 

•/ 

int  exit_flag  ■  0; 
int  size  *»  0; 
int*  buf; 
int  buf.size; 

CMD_INFO  cmdjnfo; 

MAP_INFO  map_info; 
vector  tc8t_8,  tcst_g; 
int  c_result; 
mapc_map; 

routcr3  router3a(in_ports  jns,out_ports,outs); 
map_cni  map_cntcr, 
s_los  losl: 
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While  (lexit.flag) 
switch  (router3a.cin(Ltype(size))  ( 

case  SEND: 

router3a.recetve(size,(char*)&inap_info); 
n)uier3a.cind_type(size); 
biif_8izeasize/4: 
buf  ■  new  int[buf_size]; 

rouier3ajeceive<size,(chai*)buO: 

c.map  •  inap(map_infojtan_x,  in{4>Jnfo.stan_y, 

map.info^ize.x,  map_tnfo.size_y, 

map.info.grid.size,  buO: 

break; 

case  BCAST: 

router3ajeceive(size,(char*)&cind_info): 
map_crxer.set_value<c  _map): 

if  (inap_crxer.inap_ciossing(cfndjfifo3tait,  cmdjnfo.goal,  test_s,  test_g))  ( 
c_re8ult  ■  losl^_8_los<test_s,  tcst_g,  c_map); 

) 

else 

c_result  ■  0; 

router3a.answer(c_result); 

break; 

case  TERMINATE: 
router3a.tenninate0; 
exii.flagB  I; 
break; 

default:  f*  Error  */ 
break; 

) 
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FILENAME . :wortcer.lnk 

AUTHOR . :  Dr.  Se-Hung  KWAK  &  Can  Ali  DUNDAR 

DATE . :  Sepionba  1993 

DESCRIPTION . :  Does  the  necessaiy  links  for  workos. 


woiker.bin 

ioutsr3.bin 

map.bin 

inap_crx.bin 

s_los.bin 

plane.bin 

line.btn 

vciior.tin 
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I  FILENAME . :  blest  ISO.cfg 

I  AUTHOR . :  Dr.  Se-Hung  KWAK  &  Cem  Ali  DUNDAR 

!  DATE . :  September  1993 

1  DESCRIPTION . :  This  configmation  file  are  for  IS  transputers,  one  Sun  SPARC  Station  and  one 

PC  Host  I  There  are  one  router  and  12  worker  tasks  for  each  transputeis. 


processor  host 
processor  sun  typewpc 
processor  root 
processor  pi 
proc'^ssor  p2 
processorpll 
processor  p21 
l<roccssor  pi  1 1 
processor  p2 11 
processor  pll  11 
processor  p21 11 
processor  pi  nil 
processor  p21  111 
processor  pi  111  11 
processor  p21 11 11 
processor  pll  11111 
processor  p21111 11 


wire  7 

root(0j 

hosUO] 

wire? 

root(l] 

pKl] 

wire? 

rooU2] 

p2(2] 

wire? 

rootfS] 

sun[0] 

wire? 

plI2) 

plKl] 

wire  ? 

p2[l] 

p21(2] 

wire  ? 

pi  1(2] 

pllKl] 

wire  ? 

p21(l] 

p211(2] 

wire  ? 

pi  1112] 

plllKl] 

wire  ? 

p2ll(l] 

p2111(2] 

wire? 

pill  1(2] 

plllll(l] 

wire? 

p2111(l] 

?2111112] 

wire? 

pll  111(2] 

plllllKl] 

wire? 

p21111(l) 

p211111(2] 

wire? 

pllllll(2] 

pllllllKl] 

wire  ? 

p?lllll[l] 

p2111111[2] 

1  Task  connected  to  filter  cannot  use  0  channel  of  task  therefore,  master  has  to  have  S  ins  &  outs 
!  Also  a  channel  to  filter  has  to  be  lowest  number. 


task  afserver 
task  filter 
task  master 


ins>l  outs>l 

ins«2  outs>2  data«lSk 

ins«5  outs«5  data^lSk  rile»"tr_commt.b4‘' 
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taskroutoO 

tadcnniterl 

tadciouter2 

task  iDuierl  1 

tasknMiter21 

taskiouterlll 

tadcii>uter211 

taskrouterllll 

taskiouter2111 

tadciouterlllll 

task  iouter21  111 

task  louterllllll 

task  n>uier21  nil 

taskiDuterlllllll 

task  n)uter21 11111 


ina^  outsa20  daiaB2k  filea*foaier.b4*  urgent 
insii20  outsa20  daia^2k  fUe)a"n>uier.b4*  urgent 
ii»«20outSB20daias2kfile«”router.b4*  urgent 
insB20  outs>20  data»2k  riIea''router.b4''  urgent 
ins«20  outs«20  dataB2k  fllea"router.b4*  urgent 
insa20  outsa20  daia«2k  fllea”rouier.b4”  urgent 
insa20  outsalO  data=2k  fUea’routn’.M”  urgent 
ins«20outs«20dataai2knieB"rouiBr.b4*  urgent 
inaa20out8>00(laia»2kfile«"routBr.b4"  urgent 
inss20  outsa20  data^ilk  flle«”rouiBr.b4''  urgent 
insa20outsa20<laia*2krile«''router.b4"  urgent 
in»a20  outsa20  dataa2k  rUes"router.b4”  urgent 
tns>20  outsa20  <laia»2k  rtle«"router.b4''  urgent 
insa20  outsa20  data*2k  fUe>''tt>uier.b4'  urgent 
ins>20outsa20<latap2kfl]e«"rouier.b4‘  urgent 


task  woriceiOO 
task  woriceiOl 
tftdc  wcrket02 
task  woiketOS 
task  waricei04 
task  wo(ker05 
task  woricei06 
task  woriceiC? 
task  wockeiOS 
task  woricer09 
task  woricetOlOO 
task  woricetOlOl 


ins>l  outS"!  data«27Sk  filea"worker.b4" 
ins>l  outsal  dataB27Sk  nie«"wo(ker.b4* 
ins-l  outa-l  data«27Sk  rile«''worker.b4'' 
ins>l  outSBl  dat8«27Sk  flle«''wo(ker.b4‘‘ 
ins>l  outsal  data«27Sk  filea'worker.M" 
ins«l  outa-l  data»275k  rile-”wofker.b4'' 
iitfal  outfBl  (]aia«27Sk  fllea'worker.M* 
insal  ouia>l  data«27Sk  fllea"wofker.b4" 
ins"!  ouUbI  daurB27Sk  fUea‘worker.b4'‘ 
insal  out»Bl  dataa27Sk  fUea"worker.b4" 
insal  ouisal  (lataa275k  Alea”worker.b4‘ 
insal  outsal  dataa27Sk  fllea'wotker.M" 


task  woricerlO 
task  wofkerll 
task  woricerl2 
task  woikerl3 
task  woitkerl4 
task  workerlS 
usk  wc(kerl6 
task  workerl7 
task  wofkerlS 
task  workerl9 
task  workerllOO 
task  woricerllOl 


insal  ouisbI  dataa27Sk  rilea‘‘woiker.b4” 
insal  ouis"!  dataa27Sk  rilea''worker.b4'' 
insal  outsal  dataa27Sk  filea’worker.M" 
insal  outsal  dataa27Sk  fika”worker.b4" 
insal  outsal  <Iat8a275k  rilea*worker.b4” 
insal  outsal  dataa27Sk  fUea''wofker.b4* 
insal  outsal  <Iataa275k  niea'worker.M” 
insal  outsal  dataa275k  filea’'woika.b4’ 
insal  outsal  dataa275k  filea*'wofker.b4* 
insal  outsal  daiaa275k  rilea”worker.b4* 
insal  outsal  dataa275k  fllea*worker.b4" 
insal  outsal  dataa27Sk  rilea‘'wofker.b4* 


task  worker20 
task  woricer21 
task  wo(1cer22 
task  worker23 
task  wor1rer24 
task  workei2S 
task  worker26 
task  worker27 


irtsal  out^l  dataa275k  rilea*workcr.b4” 
insal  outsal  dataa275k  filea"wofker.b4* 
insal  outsal  data«275k  rilea''worker.b4* 
insal  outsal  dataB275k  filea” worker .M" 
insal  outsal  dataa275k  rilea”worker.b4" 
insal  outsal  dataa275k  riiea”workcr.b4'' 
insal  outsal  dataa275k  fika’worker.M" 
insal  outsal  dataa27Sk  fHea” worker. b4* 
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task  wokei28 
task  woricer29 
task  waricer2100 
task  workei^lOl 
task  woricer  110 
task  workerlll 
task  woricer  112 
task  woricffll3 
task  woricerlU 
task  woricerllS 
tadc  woricer  116 
task  woricerll? 
task  woricerllS 
task  woricall9 
task  woricerll  100 
task  wotkerlllOl 

task  woricerll  10 
task  woricerllll 
task  workerl  112 
task  woricerll  13 
task  woricer]  114 
task  woricer!  115 
task  woricerll  16 
task  woricerll  17 
task  workerl  118 
task  woricerll  19 
task  woricerll  1100 
task  workerl  11 101 

task  woricerll  110 
task  woricerllll  1 
taskw(rkerllU2 
task  woricerl  1 1 13 
task  woricerll  114 
task  workerl  11  IS 
task  workerl  11 16 
task  woricerllll? 
task  woricerll  118 
task  workerl  1 1 19 
task  workerlll  1100 
task  workerlllllOl 

task  workerl  1 1 1 10 
task  woricerllll II 
task  workerl  1 1 1 12 
task  workerlllll3 
task  workerllllU 
task  workerlll  1  IS 
task  workerl  11116 
task  woricerll  11 17 


insal  out^l  data^7Sk  Glea'wotker.M* 
insal  outsal  daia)B275k  files*wotker.b4* 
insal  out^l  dataiB27Sk  fUeB’wotker.M'' 
insal  out^l  data«27Sk  fUea’worker.M' 
insal  outsal  daiaa27Sk  fUea''wotker.b4* 
inswl  out»Bl  dataai27Sk  niea'worker.M* 
insal  outsal  dataa27Sk  filea''wor1cer.b4'' 
insal  outsal  dataa275k  filea'worker.M* 
insal  outsal  dataa27Sk  fUea'worker.M” 
insal  outsal  <iaiaw27Sk  fUea*wotker.b4* 
insal  outsal  datap27Sk  fUea'wotker.M* 
insal  out^l  (laiaa27Sk  fUea"worker.b4* 
insal  outsal  daiaa275k  fUea'wotker.M* 
insal  outsal  dataa27Sk  {Uea'worker.M* 
insal  outsal  daiaa27Sk  fUea'woricer.M* 
insal  outsal  daiaa27Sk  fUea*worker.b4” 

insal  outsal  dataa27Sk  filea''worker.b4'' 
insal  outsal  daiaa27Sk  filea'wotker.M'' 
insal  out^l  dataa27Sk  Alea'worker.M'' 
insal  outsal  (]aiaa27Sk  fUea*woricer.b4’ 
insal  outsal  dataa27Sk  filea''woricer.b4‘ 
insal  outsal  dataa27Sk  fUea''worker.b4'' 
insal  outsal  dat8a27Sk  fUea’wotker.M'' 
insal  outsal  dataa27Sk  filea''woricer.b4* 
insal  outsal  dataa275k  filea''worker.b4'' 
insal  outsal  dat&a27Sk  fUea’worica.M” 
insal  outsal  (]ataa27Sk  filea'worker.M” 
insal  outsal  dataa27Sk  ftlea”worker.b4'' 

insal  outsal  dataa27Sk  filea*worker.b4‘ 
insal  outsal  dataa27Sk  filea’woricer.M" 
insal  outsal  datsa27Sk  rilea''worker.b4'' 
insal  out^l  daiaa27Sk  filea”worker.b4” 
insal  outsal  dstaa27Sk  rilea''worker.b4” 
insal  outsal  (lataa27Sk  fUea'worker.tyi* 
insal  out^l  dataa27Sk  niea’wotker.M'' 
insal  outs*l  <latta27Sk  filea'worker.M* 
insal  outsal  dataa27Sk  ftlea'worker.M* 
insal  outsal  datsa27Sk  filea'worker.M” 
insal  outsal  dataa27Sk  filea'worker.M” 
insal  outsal  dataa27Sk  filea'worker.M' 

iioal  outsal  dataa27Sk  filea'worker.M” 
insal  outsal  daiaa27Sk  fUea’woricer.M” 
insal  outsal  dstsa27Sk  filea'worker.M” 
insal  outsal  dataa27Sk  filea'worker.M' 
insal  outsal  dataa27Sk  filea’worker.M” 
insal  outsal  dataa27Sk  fUea'woricer.M” 
insal  outsal  daiaa27Sk  fUea'worker.M' 
insal  outsal  daiaa27Sk  fUea’worker.M” 
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taskworicerlinig 
nskworicBrU1119 
task  woricerlll  11100 
task  warkrrlllll  101 


task  woricerllllllO 
task  woricerllll  111 
task  w(xkBrllllll2 
taskworicerllllllS 
task  woricerllll  114 
task  wockerllllllS 
task  woricerllll  116 
task  woricerllll  117 
task  woricerllll  118 
task  woricerllllll9 
task  woricerllll  11100 
task  wotkerllll  11101 

task  wuricerlll  11110 
task  woricerlll  11111 
task  woricer!1111112 
task  woricerlll  111  13 
task  woricerlll  11114 
task  woricerlll  llllS 
task  woricerlll  111  16 
task  workerlllllll? 
task  woricerlll  11118 
task  woricerlll  11 119 
task  worker  1 1 1 1 1 1 1 100 
task  worker  1 1 1 1 1 1 1 101 


task  worker210 
task  woricei21 1 
task  wofker212 
task  worker2I3 
task  worker214 
task  woricer21S 
task  woricer216 
task  worker217 
task  worker218 
task  warker219 
task  workei21 100 
task  woiker2110l 

task  woricer21 10 
task  worker21 1 1 
task  worker21l2 
task  woricer2113 


iits-1  outs-1  daia<-27Sk  fUe«*watker.b4* 
iittal  outSBl  dataii27Sk  fUea'worker.M'' 
insBl  out»Bl  data»i27Sk  fUea’woiker.M* 
insal  outSBl  dataB27Sk  fUeB’woricer.M'' 


insal  outsal  dataB27Sk  ftlea''wofker.b4” 
insal  out^l  data^7Sk  filea’worker.M" 
insal  outSBl  (IatBB27Sk  fUea'woiker.M" 
ii»»l  out^l  datap27Sk  flleB'woricer.M'' 
insal  out^l  dataB275k  fUea’waricer.M" 
insal  outsal  data»275k  fileB*woricer.b4* 
insal  outsal  dataB27Sk  ftleB''waricer.b4" 
insal  outs>l  data<B275k  ftlea''woricer.b4” 
ins-1  outs-1  data-27Sk  me«*woricer.b4* 
ins-1  outs-l  data-27Sk  fUsa''woiker.b4” 
ins-1  outs-1  data-275k  fUe-''woricer.b4* 
ins-1  outs-1  data«275k  fUe-'wofker.M'' 

ins-1  outs-l  data-275k  fUe-’wotker.M*' 
ins-1  out^l  daia-27Sk  file-''worker.t>4'' 
ins-1  outs-l  data-27Sk  file-*worker.b4” 
ins-1  outs-1  data-27Sk  fUe-”worker.b4” 
ins-1  outs-l  data-27Sk  file-'worker.M" 
ins-1  outs-1  data-275k  file-''woricer.b4* 
ins-1  outs-1  <lata-27Sk  file-''woricer.b4’ 
ins-1  outs-1  daia-27Sk  nie-''woricer.b4” 
ins-l  outs-l  data-275k  file-''worker.b4'' 
ins-1  outs-1  dais-27Sk  file-*woricer.b4'' 
ins-1  outs-1  data-27Sk  file-''woricer.b4'' 
ins-1  outs-1  data-275k  file-*worker.b4* 


ins-1  outs-1  data-275k  ftle-''worker.b4" 
ins-l  out^l  data-27Sk  rile-*wofker.b4” 
ins=l  outs=l  dat£-275k  file-'woricer.M' 
ins-l  outs-l  daia-275k  rile-*woricer.b4'‘ 
ins-l  outs-1  data-27Sk  rile-'woricer.M” 
ins-l  out^l  data-275k  file-”woiker.b4* 
ins-l  outs-1  dataB275k  file-'woricer.M” 
ins-l  outs-1  data-275k  rile-’wotker.b4” 
ins-l  outs-1  data-275k  file-*woricer.b4” 
ins-l  outs-l  dat8-27Sk  nie-”worker.b4* 
ins-l  outs-1  data-27Sk  file-"woricer.b4* 
ins-l  outs-l  data-27Sk  file-”worker.b4* 

ins-l  outs-1  data-27Sk  file-''woricer.b4* 
ins-l  out^l  data-27Sk  flles''woricer.b4'' 
ins-l  outs-1  data-27Sk  rile-''woricer.b4* 
ins-l  outs-1  dataB275k  rile-''worker.b4” 
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task  wQricer2 114 
task  WQricu211S 
task  w(vkei2116 
task  w«kei2ll7 
task  wQrker2ll8 
task  woricei2119 
task  worker2l  1100 
task  worixr2l  1101 

task  woricer2l  110 
taskworker21111 
task  workeT21 112 
task  w(iker2l  113 
task  waricer21114 
task  wockei2111S 
task  wotker21 116 
task  workei21117 
task  workef21 118 
task  worker21 119 
task  workei2llll00 
task  workeir2l  1 1 101 

taskworkei211110 
taskwaker2lllll 
task  w(vker211112 
taskworica211113 
taskw(aker2llll4 
taskworicer2llll5 
taskworkei211116 
task  w(xkei2llll7 
task  woricet21 1 1 18 
task  worker21 1 1 19 
task  wo(ker21 1 1 1 100 
taskwo(ket21111101 

task  worica21 11110 
task  woricei21 11111 
taskwotket2lllll2 
task  woricer21 1 1 1 13 
taakwo(ker2lllll4 
taskwoikef211111S 
taskworke[2111116 
Ltskworker2111117 
task  worker2111118 
task  woiket2111119 
task  woiker211 111100 
task  worker21 1 1 1 1 101 

taskworker21111110 

taskworker21111111 

taskworker2nini2 


insal  out^l  (lataii275k  fileB"woricer.b4* 
insal  outsal  data«27Sk  filea”wo(ker.b4‘' 
insal  outsal  dats^27Sk  fUeB’woricer.M” 
insal  out^l  daiaa27Sk  fileB*wo(ker.b4" 
insal  outSBl  data*27Sk  fUeB”woricer.b4" 
ins*!  outSBl  data«27Sk  filea*'wofker.b4’ 
insal  outsal  dataB27Sk  flleB''wofker.b4'' 
insal  outsal  daia«275k  fUeB''woiker.b4’ 

insal  outa*!  dataB275k  fllea’'worker.b4'' 
insal  out^l  dataiB27Sk  fileB''wo(ker.b4‘' 
ifis«l  outsvl  daiaa275k  fUe«"wofker.b4*' 
insal  outffil  dataB27Sk  fllen"worker.b4’ 
ins*l  out^l  dai»K27Sk  filea"worker.b4* 
insal  outsal  dataa27Sk  fUea’woiker.l^’ 
ins>l  outsal  data«27Sk  fUeB''worker.b4’ 
ins«l  outssl  dataa27Sk  fUea'worker.M” 
insal  out^l  (]ataB27Sk  flie>"worker.b4’ 
ins"l  outssl  daiaiC7Sk  filea"wofker.b4” 
insal  outsal  dataiB27Sk  fllea"wo(ker.b4'' 
ins^l  outsal  data>27Sk  fUea'wofker.M” 

ins«l  outsal  dataa27Sk  niea'‘wotker.b4'' 
insal  outsal  dataa275k  nieB”wofker.b4’ 
insal  out^l  data*27Sk  filea"wo(ker.b4* 
ins*l  outsal  data«275k  file«''wofker.b4'' 
ins«l  outsal  data>27Sk  fUe«"woricer.b4’ 
insal  outsal  da<aK27Sk  files"wo(ker.b4* 
insal  outs>l  daia«27Sk  fUea”wofker.b4” 
insal  outaal  dataa27Sk  fUeB"wo(ka.b4'' 
insal  outsal  (lata»27Sk  filea"wofker.b4* 
insal  outsal  dataa27Sk  fUea*wo(ker.b4'' 
insal  outsal  dataa275k  filea''wotker.b4* 
insal  outsal  dataw27Sk  filea'*worker.b4” 

insal  out^l  dataa275k  niea‘'woiker.b4* 
insal  outaal  daiaa27Sk  flIea"woika'.b4” 
insal  outsal  dataa27Sk  niea"wofka'.b4'' 
insal  outsal  (iataa275k  filea'wofker.M" 
insal  outsal  (lataa27Sk  rtlaa‘'wofker.b4'' 
insal  outsal  dataa275k  fika’worker.M’ 
insal  outaal  dataa275k  rilea'‘worker.b4* 
insal  outsal  daiaa27Sk  filea"worker.b4* 
insal  outsal  dataa275k  rilea"wofker.b4* 
insal  out^l  dataa275k  filea'woiker.M’ 
insal  outaal  dataa275k  rilea‘'worker.b4* 
insal  outsal  daiaa275k  fiIe»-*wofker.b4" 

insal  outsnl  daiaa275k  filea'wofker.M'' 
insal  outsal  dataa275k  fi]ea''worker.b4* 
insal  outsal  dataa275k  rilea''wofker.b4* 
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tide  wQriBi2ni  1113 
ttde  wof1cef21 1 1 1 1 14 
uittwa1cBi2111111S 
tisk  worker21111116 
task  w«ker21111117 
task  warkef21  111  118 
task  woricer21 11 1119 
task  woricei21  111  11100 
task  warkcs(21  111  11101 


ins"!  out^l  datt*27Sk  fUe** 
inaal  outS"!  dat»«27Sk  file"" 
insBl  outpil  danpi275k  fUe** 
ins*l  out^l  data>B275k  fUea* 
insal  outsal  dataa27Sk  fUeB* 
ins*l  outSBl  dataa27Sk  fUe*” 
ins^l  out^l  data^27Sk  files' 
insal  outpil  datap275k  files' 
inssl  out^l  datas275k  files' 


IPon  numbers  0 ...  3  for  routers. 

IPort  numbers  4  ...  for  tasks(wofkers). 


place  afserver  host 

place  filter  root 

place  master  root 

place  routaO  root 

place  wofkeiOO  root 

place  woikeiOl  root 

place  worket02  root 

place  wofke«03  root 

place  workei04  root 

place  wotkeiOS  root 

place  wofkei06  root 

place  worketO?  toot 

place  woikeKlS  root 

friace  worker09  root 

place  wotkeKIlOO  toot 

place  wotkeKIlOl  root 

place  routerl  pi 

place  workerlO  pl 

place  woikerl  1  pl 

place  workerl2  pl 

place  wofkerl3  pl 

place  wotkerl4  pl 

place  wofkerlS  pl 

place  wotkerl6  pl 

place  workerl7  pl 

place  workclS  pl 

place  wofkerl9  pl 

place  worker  1100  pl 

place  woikerl  101  pl 

place  routerl  1  pll 

place  workerl  10  pll 

place  workerl  1 1  pll 

place  workerl  12  pll 
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2^222  2  22  22 


place  woricerl  13  pi 

pbice  woricerl  14  pi 

place  workerl  IS  pi 

place  woricerl  16  pi 

place  woricerl  17  pi 

place  woricerl  18  pi 

place  woricerl  19  pi 

place  workerl  1100  pi 

place  woricerl  1101  pi 


place  routerl  11  pi 

place  workerl  1 10  pi 

place  workerl  111  pi 

place  workerl  112  pi 

place  worker!  1 13  pi 

place  workerl  1 14  pi 

place  workerl  1  IS  pi 

place  workerl  1 16  pi 

place  workerl  1 17  pi 

place  workerl  118  pi 

place  workerl  1 19  pi 

place  workerl  11 100  pi 

place  workerl  11 101  pi 

place  routerllll  pi 

place  workerl  11 10  pi 

place  workerll  111  pi 

place  workerl  11 12  pi 

place  workerl  11 13  pi 

place  workerl  1114  pi 

place  workerl  11  IS  pi 

place  workerl  1116  pi 

place  workerl  1117  pi 

place  workerl  11 18  pi 

place  workerl  1119  pi 

place  workerl  1 1 1 100  pi 

place  workerll  11101  pi 

place  routerl  11 11  pi 

place  workerl  1 1 1 10  pi 

place  workerll  1111  pi 

place  workerl  1 1 1 12  pi 

place  workerl  1 1 1 13  pi 

place  workerll  11 14  pi 

place  workerl  mis  pi 

place  workerl  1 1 1 16  pi 

place  workerll  11 17  pi 

place  workerl  1 1 1 18  pi 

place  workerl  11119  pi 


place  waikerllllllOO 

pllll 

place  woricerll  1 1 1 101 

pllll 

place  routerllll  11 

pill) 

place  wockerllll  110 

pill] 

place  wortcerl  11 1111 

pllll 

place  wofkerllll  112 

pill] 

place  woricerll  11 113 

pllll 

place  woricerl  1 1 1 1 14 

pill] 

place  woricerll  nils 

pllll 

place  woricerllll  116 

pin: 

place  woricerl  11 1117 

pin: 

place  woricerllllllS 

pin 

place  woricerl  11 1119 

pin 

place  woricerl  1 1 1 1 1 100 

pin 

place  woricerl  1 1 1 1 1 101 

pin 

place  Touterlllllll 

pin 

place  woricerl  1 1 1 1 1 1 0 

pin 

place  worker  1 1 1 1 1 1 1 1 

pin 

place  woricerl  1 1 1 1 1 12 

pin 

place  worker  1 1 1 1 1 1 1 3 

pill 

place  worker  1 1 1 1 1 1 14 

pin 

place  woricerl  11  HUS 

pin 

place  woricerl  1 1 1 1 1 16 

pin 

place  workerl  1 11 1 1 17 

pin 

place  workerl  1 1 1 1 1 18 

pin 

place  worker  1 1 1 1 1 1 19 

pin 

place  workerll  11 111100 

pin 

place  woricerllllll  1101 

pin 

place  rouier2 

P2 

place  wotker20 

P2 

place  workef21 

p2 

place  wotket22 

P2 

place  wurker23 

p2 

place  woiker24 

p2 

place  worker2S 

p2 

place  woricei26 

p2 

place  worker27 

P2 

place  worker28 

p2 

place  woricef29 

p2 

place  woricer2l00 

p2 

place  worker2101 

p2 

place  router21 

P21 

place  wotkei2I0 

p21 

place  worker21 1 

p21 

place  worker212 

p21 

place  worker2 13 

p21 

place  worica214 

p21 

place  worka2lS 

p21 

place  worica2l6 

p21 

place  wo(kei2l7 

P2l 

place  wofker218 

p21 

place  wotlcer219 

p21 

place  wofker21 100 

p21 

place  woikei2l  101 

p21 

place  nxiiei211 

p211 

place  woricer21 10 

p211 

place  wofker21 11 

p211 

place  worker21 12 

p211 

place  wofker21 13 

p211 

place  woiker21 14 

p211 

place  wofker2l  15 

p211 

place  wofka21 16 

p211 

place  wofker21 17 

p211 

place  wofker2l  18 

p211 

place  woricer21 19 

p2n 

place  woito2 11 100 

p211 

place  woikei21 1 101 

p211 

place  iouter21 11 

p2111 

place  worice(21 110 

p2111 

place  woricer21111 

p2111 

place  woite21 112 

p2111 

place  wofker21 113 

p211I 

place  woricer21114 

p2111 

place  wcfker2l  115 

p2111 

place  woite21 1 16 

p2111 

place  workei211I7 

p2111 

place  wotker21 118 

p2111 

place  wofker211I9 

p2111 

place  woiker21 1 1 100 

p2111 

place  worker21 11 101 

p2111 

place  rouier211 11 

p2111 

place  woilcet21 1 1 10 

p2111 

place  wofkei211111 

p2111 

place  worker211112 

p2Ul 

place  workef211113 

p2111 

place  wortcei21 1 1 14 

p2111 

place  woi1cei21 1 1 15 

p2111 

place  workei21 1 1 16 

p2111 

place  worker21 1 1 17 

p2111 

place  wofker21 1 1 18 

p2ni 

place  wo(kei21 1 1 19 

p2111 

place  woiter21 11 1100 

p2111 

place  worker21 11 1101 

p2111 
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place  rouiBf21U  11 

P211111 

place  wo(kef21 11 110 

P211111 

place  wo(ker2111111 

P211111 

place  woricei21 1 1 1 12 

p211111 

place  wof1cer21 11113 

p211111 

place  wofker21 1 1 1 14 

p211111 

place  wofto21 11 115 

p211111 

place  wofkei21 1 1 1 16 

P211111 

place  wof1cet21 1 1 1 17 

P211111 

place  wo(to21 1 1 1 18 

p211111 

place  wofkerll  1 1 119 

p211111 

place  wocker21 1111100 

p211111 

place  woricerZl  1 1 1 1 101 

p211111 

place  iouiei21111 11 

P2111111 

place  worker21 111110 

p2111111 

p’aceworker21111111 

p2111111 

place  worfca21 1111 12 

p2111111 

place  wotter2 1 1 1 1 1 1 3 

p21Illll 

place  woricei211  111  14 

P2111111 

place  wofker2 1 1 1 1 1 1 S 

p21111!l 

place  wortcer21111116 

p2111111 

place  workei211  111  17 

P2111111 

place  worker2 1 1 1 1 1 1 8 

p2111111 

place  worto21 1 1 1 1 19 

P2111111 

place  woiter2 1 1 1 1 1 1 100 

p2111111 

place  warker21 1 1 1 1 1 101 

p2111111 

connect  ?  afserveilO] 

filterlO] 

connect  ?  filtertO] 

afserv^O] 

connect?  niterfl] 

master[l] 

connect  ?  mastetll] 

niterd] 

connect  ?  master(2] 

ix>utei0[0] 

connect  ?  routei0[0] 

niastert2] 

connect?  routeiO[l] 

n>uterl[0] 

connect  ?  roiiterl[0] 

iouteiO(lj 

connect  ?  routeiO[2] 

n>uter2[0] 

connect  ?  router2[0] 

routei0(2] 

connect  ?  routeiO(4] 

workei00[01 

connect  ?  wofkei00(0) 

routciOl4] 

connect  ?  routeiO[S] 

wortei01[0] 

connect  ?  workctOKO] 

routeiO[S] 
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connect  ?  routei0{6] 
connect  7  wotkei02[0] 

workei02[0] 

routBiO[6] 

connect  ?  routeiOR] 
connect  ?  wofkei03(0] 

workci03(0] 

routeiOr?] 

connect  ?  roijteiO[8] 
connect  ?  wo(to04[0] 

wotkei04(0] 

routeiO(8] 

connect  ?  iouteiO[9] 
connect  ?  w(RlceiOS[0] 

woitaOS[0] 

routeiO(9] 

connect  ?  routef0[10] 
connect  7  wotkef06[0] 

workei06[0] 

routeiOdO] 

connect  7  routeiO[ll] 
connect  7  workci07(0] 

workcr07(0] 

routetOdl] 

connect  7  n>uteiO[l2] 
connect  7  workei08[0] 

workei08(0] 

routeiOdi] 

connect  7  routeiO[13] 
connect  7  workeH)9[0] 

workei09[0] 

routeiOd3] 

connect  ?  routetOiM] 
connect  7  wofkei0100[0] 

woricei0l00[0] 

routeiOd4] 

connect  7  routeK)[lS] 
connect  7  workei0101[0] 

workeiOlOUO] 

routeiOdS] 

connect  7  routerl[l] 
connect  7  routerl  1(0] 

routerl  1(0] 
routerl(l] 

connect  7  routerl  (4] 
connect  7  workerl0[0] 

workerl0(0] 
routerl  [4] 

connect  7  routerl  [S] 
connect  7  worfcerl  1[0J 

workerll(0] 
routerl  [S] 

connect  7  routerl  [6] 
connect  7  woilcerl2(0] 

workerl2(0] 
routerl  (6) 

connect  7  routerl  [7] 
connect  7  workerl3(0] 

wofkerl3(0] 
routerl  [7J 

connect  7  routerl  [8] 
connect  7  wurkerl4[0] 

workerl4[0] 
routerl  (8] 
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connect  ?  roulBrl(91 
connect  7  workerl5[0] 


woricerl5[0] 
router  1  [9] 


connect  ?  touterl[10] 
connect  7  woilcerl6(0] 

connect  7  routerl  [11] 
connect  7  wo»kcrI7(01 

connect  7  roulerl[12] 
connect  7  wockerl8[0] 

connect  7  TOiiterl(13] 
connect  7  workerl9(0] 

connect  7  routerl(14] 
connect  7  workeil  100[0) 

connect  7  routerI(lS] 
connect  7  worker  1  lOi  [C] 


connect?  routerl  111] 
connect  ?  routerl  1 1(0] 

connect  ?  routerl  114] 
connect  ?  workerl  10(0] 

connect  ?  routerl  1(S] 
connect  7  workerl  11(0] 

connect  7  routerl  1  [6] 
connect  7  workerl  12(0] 

connect  7  routerl  1(7] 
connect  7  workerl  13(0} 

connect  7  routerl  1(8] 
cormect  7  workerl  14(0) 

cotuiect  7  routerl  1(9] 
connect  7  workerl  15(0] 

connect  ?  routerl  1(10] 
connect?  workerl  16(0] 


connect  ?  routerl }  ( 1 1  ] 
connect  ’  workerl  17(0) 


worker  16(0] 
routerl  ( 10] 

woikerl7(0) 

rouiBrl(ll] 

wofkerl8(Ul 

routBrl(12] 

worker  19(0] 
iouterl(13] 

workerl  100(0] 
rouierl(14] 

workerl  101(0] 
routerl(15] 


routerl  11(0] 
route.'!  1(1] 

worker!  10(0) 
routerl  1(4] 

workerl  11(0] 
routerl  1(5] 

workerl  12(0] 
routerl  1(6] 

workerl  13(0] 
routerl  1(7] 

workol  14(0] 
routerl  1(8] 

workerl  15(0] 
routerl  1(9] 

workerl  16(0; 
routerl  1(10] 


worker!  17(0) 
routerl  I|i  1) 


l^ 


connect  ?  nHiterl  1(12] 
connect  7  wofkerl  18(0] 

worker!  !8[0] 
iouter!l(12] 

connect  ?  routerl  1[  13] 
connect  ?  worker!  19[0] 

worker!  !9[0] 
iouier!!(13] 

connect  ?  router!  ![14] 
connect  ?  worker!  1  !00(0] 

worker!  !!00[0] 
routerl!  [14] 

connect  ?  router!  1[!S] 
cofuiect  7  worker!  1  !01[0] 

worker!  1 10!  [0] 
rouierlldS] 

coiuiect  7  routerl !!( 1) 
connect  7  n  terllll(0] 

router!  !!![0] 
router!!!]!] 

connect  7  routerl ! !  [4] 
conitect  7  worker!  1  !0(0] 

worker!  !!0[0] 
router!  11  [4] 

connect  7  router! !  1[S] 
connect  7  worker !  1 1 1  [0] 

worker!  11  ![0] 
router!  11(5] 

connect  7  routerl !  1  [6] 
cotutect  7  worker!  1  !2[0] 

worker!  1!2[0] 
router!  11  [6] 

connect  7  routerl !  1  [7] 
connect  7  worker! !  !3[0] 

worker!  !13[0] 
router!!!  [7] 

coiutect  7  router! !  1[8] 
connect  7  worker!  1  !4[0] 

worker!  1!4[0] 
router!!!  [8] 

cotutect  7  routerl !  1  [9] 
connect  ?  worker!  1  !S[0] 

workal!!5[0] 
router!!!  [9] 

coiutect  7  router! !![  10] 
connect  7  worker !  1  !6(0] 

worka!!!6[0] 
router!  !!(!0] 

connect  7  rxtuterllKl!] 
conitect  7  worker! !  !7(0i 

worker!  !!7(0] 
router!!!]!!] 

connect  7  router !!!( 1 2] 
coiutect  7  worker! !  !8(0] 

worker!  !!8]0] 
router!  !!]I2] 

coiutect  7  router! !!  ( !  3] 
connect  ?  worker! !  19(0) 

worker! !  !9(0] 
router!  !!]!3] 

connect  ?  router) !  !I!4j 
connect  7  worker! !  1  !00(0] 

worker!  !!!00|0] 
muter!  !!]!4] 

conitect  ?  router!  !!(!5) 
connect  ?  worker!  !!!0i(0] 

worka!!!!0!(0] 
router!!!]  15] 
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connect  7  muter  1 1 1 1  ( 1  ] 
connect  7  louierl  1 1 11(0] 


routerllllUO] 

rouierlllKl] 


connect  7  routerl  1 1 1  (4] 
connect  ?  workerl  1 1 10(0] 

workerl  1 1 10(0] 
routerl  111(4] 

connect  7  routerl  111(5] 
connect  7  worker  1 1 1 1 1  (0] 

workerl  111  1(0] 
routerl  11 1(5] 

connect  7  routerl  111(6] 
connect  7  workerl  1 1 12(0] 

workerl  11 12(0] 
routerl  11 1(6] 

connect  7  routerl  1 1 1(7] 
connect  7  workerl  1 113(0] 

workerl  11 13(0] 
routerl  11 1(7] 

connect  7  routcrllll(8] 
connect  7  workerl  1 1 14(0] 

workerl  1 1 14(0] 
routerl  11 1(8] 

connect  7  routerl  1 1 1  (9] 
connect  ?  workerl  1 115(0] 

workerl  1 1 15(0] 
routerl  11 1(9] 

connect  7  router  1 1 1 1  ( 10] 
connect  7  workerl  1 1 16(0] 

workerl  1 1 16(0] 
routerl  11 1(10] 

connect  7  router  1 1 1 1  ( 1 1  ] 
connect  7  workerl  1 1 17(0] 

workerl  11 17(0] 
routerl  11 1(11] 

coiutect?  routerl  11 1(12] 
connect  7  workerl  1 1 18(0] 

workerl  11 18(0] 
routerl  lll(12j 

coruiect  7  routerl  1 1 1  [  13] 
corutect  7  workerl  1 1 19(0] 

workerl  11 19(0] 
routerl  11 1(13] 

connect  7  routerl  11 1(14] 
connect  7  workerl  111  100(0] 

workerl  1 1 1 100(0] 
routerl  11 1(14) 

coruiect  7  router  1 1 1 1  ( 1 5] 
connect  7  workerll  11101(0] 

workerl  111  101(0] 
routerl  11 1(15] 

connect  7  routerlllll(l] 
connect  ?  routerl  1111 1(0] 

rouierlllllUO] 

routerlllll(l] 

connect  7  routerl  1 1 1 1(4] 
connect  ?  workerl  1 1 1 10(0] 

workerll  11 10(0] 
routerl  1 1 1 1  (4] 

connect  7  routerl  1111(5] 
connect  7  workerl  111  11(0] 

workerl  111  11(0] 
routerlllll(5] 
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connect  7  routerl  111 

1161 

workerl  11 

112(0] 

connect?  woilcerl  11 

112[0] 

routerllll 

1(6] 

connect  ?  routerl  1 1 1 

im 

workerl  11 

113(0] 

connect  ?  workerl  1 1 

113[01 

routerl  111 

1(7] 

connect?  routerl  111 

1[8] 

workerl  11 

114(0] 

connect  ?  workerl  1 1 

114[0] 

routerl  111 

1(8] 

cotmect?  routerl  111 

1(9] 

workerlll 

115(0] 

cofuiect  ?  workerl  1 1 

115(0] 

routerllll 

1(9] 

coruiect?  routerl  111 

1(10] 

workerlll 

116(0] 

cofuiect  ?  workerl  1 1 

116(0] 

routerllll 

1(10) 

coruiect  ?  routerl  1 1 1 

1(11] 

workerlll 

117(0] 

connect  ?  workerl  1 1 

117(0] 

routerl  1 1 1 

1(11] 

connect?  routerl  111 

1(12] 

workerlll 

118(0] 

coruiect  ?  workerl  1 1 

118(0] 

routerl  111 

1(12] 

connect  ?  routerl  1 1 1 

1(13] 

workerlll 

119(0] 

connect  ?  workerl  1 1 

119(0] 

routerllll 

1(13] 

coruiect  ?  routerl  1 1 1 

1(14] 

workerlll 

11100(0] 

connect  ?  workerl  1 1 

11100(0] 

routerllll 

1(14] 

connect  ?  routerl  111 

1(15] 

workerlll 

11101(0] 

connect?  workerl  11 

11101(0] 

routerl  1 1 1 

1(15] 

coruiect  ?  routerl  1 1 1 

11(1] 

routerl  1 1 1 

111(0] 

coruiect  ?  routerl  1 1 1 

111(0] 

routerl  1 1 1 

11(1] 

connect  ?  routerl  1 1 1 

11(4] 

workerlll 

1110(0] 

coruiect  ?  worker!  1 1 

1110(0] 

routerl  1 1 1 

11(4] 

connect  ?  routeri  1 1 1 

11(5] 

workerlll 

1111(0] 

connect  ?  workerl !  1 

1111(0] 

routerllll 

11(5] 

connect  ?  routerl  1 1 1 

11(6] 

workerl  1 1 

1112(0] 

coruiect?  workerl  11 

1112(0] 

routerl  1 1 1 

11(6] 

coruiect  ?  routerll  1 1 

11(7] 

workerlll 

1113(0] 

coruiect  ?  workerl  1 1 

1113(0] 

routerl  1 1 1 

11(7] 

coruiect  ?  routerl  1 1 1 

11(8] 

workerlll 

1114(0] 

coruiect  ?  workerl  1 1 

1114(0) 

routerl  1 1 1 

11(8] 
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connect  7  louierlll  11 1[9]  woricerlllUlS[0] 

connect?  wo(kerlH:ilS(0]  iDuiBrllllll[9] 


connect  ?iouterl  11 11 1(10]  woikerl  111  116(0] 
connect?  wofkerl  111  116(0]  routerllllll(10] 


connect  ?routerll  1111(11]  woikerl  111  117(0] 

connect?  workerl  111  117(0]  routerll  1111(11] 


connect  ?roiiterl  11 11 1(12]  wotkerll  11118(0] 

connect?  workerl  111  118(0]  rouierlll  111(12] 


connect  7  routerllll  11(13]  wotkerll  11 119(0] 

connect?  workerllU119(0]  routBrllllll(13] 


connect?  routerll  111  1(14]  workerl  111  11 100(0] 

connect  7  workerl  111  11 100(0]  routerllll  11(14] 


connect?  routerll  1111(15]  workerl  111  11101(0] 

connect?  workerl  111  11 101(0]  routerlllllUlS] 


connect  ?n)uterl  111  111(4]  workerl  111  11 10(0] 

connect?  workerllll  1110(0]  rouierlll  1 111(4] 


connect?  routerll  111  11(5]  workerl  1111 111(0] 
connect?  workerl  111  11 11(0)  routerll  11111(5] 


connect?  routerll  11 111(6]  workerllll  1112(0] 
connect  7  workerl  111  1112(0]  rouierlll  1111(6] 


connect  ?routerl  11 1111(7]  workerl  111  1113(0] 
coruwct  ?  workerl  11 11 113(0]  routerll  111  11(7] 


connect  ?  routerl  1 1 1 1 1 1(8]  workerl  11111 14(0] 
connect?  workerl  111  1114(0]  routerl  1111 11(8] 


connect?  routerl  111  111(9]  workerl  111  11 15(0] 
connect?  woikerlllllll5(0]  routerll  11 111(9] 


corutect?  routerllll  111(10]  workerl  111  11 16(0] 

connect?  workerlllllll6(0]  routerll  11 111(10] 


corutect?  routerl  11 1111(11]  workerl  111  11 17(0] 
connect?  workerllll  1117(0]  routerll  11 111(11] 


connect?  routerl  11 11 11(12]  workerllll  11 18(0] 
connect  7  workerllll  11 18(0]  rouierlllllll(12] 


connect?  routerl  111  111(13]  workerl  1 1 1 1 1 19(0] 
connect?  workallllll  19(0]  routerlllllll(13] 
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connect?  nHKBrlllllU[14]  wofkerllll  111100(0] 

connect?  wofkerll  11 11 1100(0]  rouirrlllll  11(14] 


connect  ?roiiterlllllli(lS] 
connect  ?  wofkerl  1 1 1 1 1 1 101  (0] 

woricerl  111  111  101(0] 
Fouterlll  1111(15] 

connect  ?  routei2(l] 
connect  ?router21(0] 
connect  ?  ioutei2(4] 
connect  ?  wofier20(0] 

toutBt21(0] 

n>uiei2(l] 

woricBi20(0] 

routei2(4] 

connect  ?  ioiJter2(S] 
connect  ?  wof1cer21(0] 

worker21(0] 

routei2(5] 

connect  ?  roiiter2(6] 
connect  ?  woricer22(0] 

wotkef22(0] 

foutei2{6] 

connect  ?  routef2(7] 
connect  ?  worker23(0] 

worket23(0] 

routef2(7] 

connect  ?  router2(8] 
connect  ?  wor1cei24(0] 

wofket24(0] 

routei2(8] 

connect  ?  routet2(9] 
connect  ?  worker2S(0] 

worker25(0] 

roulei2(9] 

connect  ?  n)utef2(10] 
connect  ?  woriLer26(0] 

worker26(0] 

iouier2(10] 

connect  ?  router2(l  1] 
connect  ?  workef27(0] 

woAei27(0] 

outei2(ll] 

connect  ?  foutef2(12] 
connect  ?  worker28(0] 

wofker28(0] 

router2(12] 

connect  ?  routef2(13] 
connect  ?  worker29(0] 

workei29(0] 

routBr2(13] 

connect  ?  routef2(14] 
connect  ?  worker2100(0] 

woitto2100(0] 

router2(14] 

connect  ?  router2(  15] 
connect  ?  wof1cer2 101(0] 

worker2101(0] 

roulef2(15] 

connect  ?  rouier21(  I]  Fouiei211(0] 

connect?  router2 11(0]  rtMJlef21(l] 
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ccnnect  7  n)iit8i21[4] 
connect  7  woricer210[0] 

warioer210(0] 

nMier21(4] 

connect  7  ioiitei21(S] 
connect  7  wo(1ctf21 1[0] 

woffcer211[0] 

routef21[S] 

connect  7  Toutef21(6] 
connect  7  wofkei212i[0] 

wo(1cer212(0] 

TOUtBt21(6] 

connect  7  n)uter21[7] 
connect  7  wofto2l3(0] 

n-a(kei213(0] 

roiiter21[71 

connect  7  roiitei21[8] 
connect  7  worker214[0] 

woiker214(0] 

roiiief21[8] 

connect  7  routei21[9] 
connect  ?  wo9'ker21S(0] 

worker21S[0] 

rouiei2l[9] 

connect  7  routei21[  10] 
connect  7  wofto216[0] 

worker216{0] 

rDutet21[lO] 

connect  7  routei21[l  1] 
connect  7  wofkertl7[0] 

wofker217(0] 

rout^Ull] 

connect  7  foutei21[12] 
connect  ?  woiter218(0] 

woiker218[0] 

n>u(ei21(12j 

connect  7  router2U131 
connect  7  wofkef219[0) 

wofter219(0] 

rouler21(13] 

connect  7  routei21[14] 
connect  7  wof1cer21 100(0] 

wo(ker2 1100(0] 
rouiei21(14] 

connect  7  rou!ei2U15] 
connect  7  wofto21 101(0) 

wof1cer21 101(0] 
n>ut^l(lS] 

connect  7  router211(l] 
connect  7  router21 1 1(0] 

iT>uter2111(0] 

toutef211[l] 

connect  7  routei21 1(4] 
connect  7  wotker21 10(0] 

woiker2110(0] 

routei211(4] 

connect  7  rouiei21 1[S] 
connect  7  wotkerZl  1 1  [0] 

woita2lll(0] 

routef211(S] 

connect  ?  n>ulef2 1 1  (6] 
connect  ?  wofker2l  12(0] 

workef2112(0] 

n>uierZll(6] 

connect  7  rouier21 1(7] 
connect  7  wo(ker21 13(0] 

wofto2113(0] 

n>utBr211(7] 
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connect  ?  n)uter21 1(8] 
connect  ?  wo(kef2114(0] 

wu(ket2114(0] 

ioutei211[8] 

connect  7  router21 1(9] 
connect  7  wofke(211S(0] 

worto2115(0] 

n)ut£i211(9] 

connect  7  ioutei2ll(10] 
connect  7  w(Hker21 16(0] 

workei2116(0] 

routei211(10] 

connect  7  routef21 1(11] 
connect  7  worker21 17(0] 

wo(ka2117[0] 

TOutet211(ll] 

connect  7  n>uter2 1 1  [  1 2] 
connect  7  wofte21 18(0] 

woiker2118(0] 

routei2ll(12] 

connect  7  ioutei21 1(13] 
connect  7  workei21 19(0] 

woiker2119(0] 

router2ll(13] 

connect  7  TOiitef21 1(14] 
connect  7  woi1cer21 1 100(0] 

woricet21 1100(0] 
rouiei211(14] 

connect  7  router21 1(15] 
connect  7  woito21 1 101(0] 

workei21 1101(0] 
routei211(lS] 

connect  7  rcHiter2 1 1 1  ( 1  ] 
connect  7  router21 1 1 1  (0] 

n)utef21111(0] 

routei2111(l] 

connect  7  router21 1 1(4] 
connect  7  worket21 1 10(0] 

wortcei21110(0] 

routo2111(4] 

connect  7  roiitet21 1 1  (5] 
connect  7  worker21 1 1 1(0] 

workei21111(0] 

routei2111[5] 

connect  7  routef21 11(6] 
connect  7  woriceT21 1 12(0] 

wor1cer21 112(0] 
routei2111(6] 

connect  7  router21 1 1  (7] 
connect  7  wofker21 113(0] 

woiter21 113(0] 
routeT2111(7] 

connect  7  roiiter2 1 1 1  (8] 
connect  7  woricer21 1 14(0] 

wofke(21 114(0] 
it>uter2111(8] 

connect  7  router21 1 1  (9] 
connect  7  wofker21 115(0] 

workei21 115(0] 
ioutei2111(9] 

connect  7  n)uter21 11(10] 
connect  7  wofker21 1 16(0] 

worker21 116(0] 
router211](10] 
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connect  7  roiitBf2111[ll]  waitsi211i7[0] 

connect?  woito21U7[0]  toulei2111[ll] 


connect  ?  :rHttei21 11(12] 
connect  ?  118(0] 

connect  ?  rouL,.71 11(13] 
connect  ?  v  r.r  -.<5121 119(0] 


wDfkcf21 118(0] 
rouMCll  11(12] 
worket21 119(0] 
ioutei211 1(13] 


co!r«r»t' :outer21 11(14]  woiker21 11 100(0] 

connect? worker2l  11 100(0]  '  iouibt21  11(14] 


connect?  n>uter21 11  (IS]  wofker21ir.01(0] 

connect worker2l  11 101(0]  rouiei2111(lS] 


connect  7  Toutet2 1 1 1 U 1  ] 

rouief211111(0] 

connect  ?  routei21 1 1 1 1(0] 

routeT21ill(l] 

connect  7  n>utei21 1 }  1(4] 

woiker211110(0] 

connect  7  workef2l  1 1 10(0] 

ioutei21111(4] 

connect  7  to*iter21 1 1 1(S] 

^otkerlll  111(0] 

connect?  workef211111(0] 

router2llll(S] 

connect  7 '  x>uter2 1 1 1 1  (6] 

woifce(211112(0] 

connect  ?  woikeri  1 1 1 12(0] 

route'/21Ill(6] 

connect  ?  routef21 1 1 1(7] 

worker211113(0] 

connect  7  worker21 11 13(0] 

router21111(7] 

connect  7  routef2 1 1 1 1  (8] 

workef21tii4(0] 

connect  7  worket2 11114(0] 

routei21111(8] 

^'xxinect  7  router21 1 1 1(0,1 

wo(kef21111S(0] 

connect  7  woricer21111M0] 

rouiei21111(9] 

connect  7  rDutei21111(10] 

woiker2llll6(0] 

connect  7  workef21 1 1 16(0] 

FOulei211 11(10] 

connect  ?  router21 1 1  Ij  ] 

woiker211117(0] 

connect  7  worker21 1 1 17(0] 

n)uter21111(ll] 

connect  7  n)utei21 111(12] 

wof1(er2llll8(0] 

connect  7  worker21 1 1 18(0] 

ioutef21111(12] 

connect  7  router21 1 1 1(13] 

woikef211119;/j, 

conf>«ct  7  wofto21 1 1 19(0] 

ioutef21111(13j 

conriec'  ?  .  ■njter2l  1 1 1(14]  wofker21 1 1 1 100(0] 

connojt  ?  v>ricri21 1 1 1 100(0]  rouief21 1 11(14] 
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connect? 

connect? 


connect? 

connect? 


connect? 

connect? 

connect? 

connect? 

connect? 

connect? 

connect  ? 
connect? 

connect? 

connect? 

connect? 

connect? 

connect? 
connect  ? 

connect? 
connect  ? 

connect? 

connect? 

connect? 
connect  ? 

connect? 

connect? 

connect  ? 
connect? 


connect? 
connect  ? 

connect? 
connect  ? 


routei21111(15] 

worker21111101[0] 


ItHltCT211111[l] 

n)uter2111111[0] 


routei211111[4] 
wofkef2n  1110(0] 

routei211111[S] 

workei2111111[0] 

roiiter21111I[6] 
woiter21 11 112(0] 

routei21 1111(7] 
W0fto2111113(0] 

routei211111[8] 
worker2l  11 114(0] 

routei211111(9] 
woricci21 11 115(0] 

routei2I  111  1(10] 
woita21  111  16(0] 

routei211111(ll] 
woricef2l  111  17(0] 

roiita21  111  1(12] 
worker21 11 118(0] 

routei21 1111(13] 
worker21 11 119(0] 

routei211 111(14] 
workef211111100(0] 

router21 1111(15] 
worker211111101(0] 


routef211 1111(4] 
woiter21111110(0] 

routef211 1111(5] 
woilLer21111111(0] 


wo(ket21 

111101(0] 

routBi211 

11(15] 

router211 

1111(0] 

routBi211 

111(1) 

workei21 

11110(0] 

rouiei211 

111(4] 

wofto21 

11111(0] 

rouiBr211 

111(5] 

worker21 

11112(01 

IDUtBl211 

111(6] 

wofto21 

11113(0] 

it>utei211 

111(7] 

w(Hket21 

11114(0] 

itHitei211 

111(8] 

workeKll 

11115(0] 

routei211 

111(9) 

workef21 

11116(0] 

roulei211 

111(10] 

wofker21 

11117(0] 

rouiei211 

111(111 

wofker21 

11118(0] 

rouiei211 

111(12] 

wor1cer21 

11119(0] 

router211 

111(13] 

woricei21 

1111100(0] 

rouier211 

111(14] 

woi1cer21 

1111101(0] 

rouiBr211 

111(15] 

worto21 

111110(0] 

routei211 

1111(4] 

woricer21 

111111(0] 

fouief211 

1111(5) 
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connect  7  roun^l  11 111[6]  woricer21111112[0] 

connect?  woi1c02in  1112(0]  routBi21 11111(6] 

connect  7  rouiei21 11 111(7]  woftoi21111113(0] 

connect  7  woitei2llll  1 13(0]  ioutei2111111(7] 

connect  7  ioutei2111 111(8]  woftei21111114(0] 

connect  7  woiter21 11 11 14(0]  rouiet21 11 111(8] 

connect  7  routei211 1111(9]  wofkei2111111S(0] 

connect?  wor(cef21 111115(0]  n)utBi21 11 111(9] 

connect  7  routei21  111  11(10]  worto21  111  116(0] 

connect?  woricer21 11 1116(0]  routei^l  11111(10] 

connect  7  routef2ll  11 11(11]  workei21111117(0] 

connect  7  worker21 11 11 17(0]  router21 11 111(11] 

connect  ?routei2ll  11 11(12]  wotker21  111  118(0] 

connect?  wor1cef211 11 118(0]  fOutef21 11111(12] 

connect7iouef2llllll(13]  woricer21111119(0] 

connect?  wofker21  111  119(0]  fOulei2111111(13] 

connect  ?tt>utei2l  11111(14]  wortcer21  111  11 100(0] 

connect  ?worker21 11 11 1100(0]  rouief2111111(14] 

connect  ?routei2lll  111(15]  worker21111 11101(0] 

connect  ?  worker?  1 1 1 1 1 1 101  (0]  routet2 1 1 1 1 1 1  ( 1 5] 


bind  input  master(4]  valuesi&SOOOOOlC  ILink3 

bind  output  master(4]  valueM&8000000C 
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APPENDIX  C  -  SOURCE  CODE  FOR  READING  TERRAIN  DATA 


This  appendix  contains  the  source  listings  of  the  C  code  developed  for  reading  a  block 
of  terrain  data  from  PEGASUS  database  into  a  specified  buffer  location  which  is  stored  in 
SUN  memory.  The  source  code  is  stored  in  files  as  listed  below; 

1.  PVO_DEC.H 

2.  PVG.DECIN 

3.  PVG.DEF.IN 

4.  get_tciT.c 
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#ifhdcf  PVO.INCLUDED 
idefine  PVO.INCLUDED 


^••********,*****,«*«**«*.****«*«******.« . . 

FILENAME:  PVG.DEC.H 

PURPOSE:  GLOBAL  PARAMETER  DECLARATION  FILE  FOR  PVG  ALGORITHMS 

DESCRIPTION:  The  PVG.DEC.H  include  file  includes  all  global  variables 
required  for  sharing  data  between  miOo'  software  components  of 
PVG  software. 

Parameter  are  divided  into  migor  categories  using  asteric  lines. 

All  global  variables  shall  be  ALL  CAPITAL  letters. 

USE  EXAMPLE: 

#include“PVG_DEC.H” 

•***«****«********«*****«»**qODESTART**************************«******/ 

#includc“PVG_DEFJbr 

f>m***m****m*0*»*m  COLOR  PARAMETERS  DECLARATIONS***********************/ 

/.♦♦••♦•••••••♦••••••TERRyyjj  data  base  DECLARATIONS********************/ 

/*  Sun  main  memory  terrain  storage  buffers*/ 
u.int  TERRAINl(MAX_BLOCKll[BLOCKl_SIZEiy*one  meter 
terrain  buffer*/ 

/*  Terrain  data  bit  assignments  valid  for  all  resolutions: 

32  1 

10987654321098765432109876543210 
I ELE I  SPARE  I  NOR  ISI VEG I GSV I 


where: 

ELE  •  elevation  firom  sea  level  to  top  of  vegetation  in  meters 
SPARE  ■  net  used 
NOR  s  4  bit  surface  normal 
S  K  sun  shade  bit 
GSV  m  gray  shade  value 
*/ 
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int  TCRRAINMAP(MAX_EAST_BLOCK][MAX.NORTH_BLC)CK]/*  terrain  map 
contains  pointen  to  terrain  data  bk>cks*/ 

int  HAVEMAP[MAX_EAST_BL0CK)[MAX_N0RTH_BL0CK)/*  Terrain  resolution 
map  tells  what  resolution  blocks  are  in  memory*/ 


/*  range  resolution  parameters  V 

int  SRMlN[R£S_RANGE_NUM];/*minimum  resolution  in  meters  */ 
int  SRMAX[KES_RANGE_NUM]y*maximum  resolution  in  meters*/ 
int  SRSTEP[RES..RANGE_NUM]7*  step  size  in  meters*/ 


/*  HSPVG  terrain  data  management  */ 

int  IF0VGRIDIMAX_EAST_BL0CK)[MAX  J^ORTH.BIXXKiy*  Terrain  grid 
to  image  map.  Specifies  the  image  location  of 
ground  points. 

EX;  IFOVGRID[E][N]v  image  i  coordinate 

in  upper  word 

■  image  j  (row)  coordinate 

in  lower  word 

« >1  if  terrain  point  is  not 

in  the  IFOV  image*/ 

r  HSPVG  terrain  data  communication  variables*/ 

u.shoitTER_PROC_HAS[MAX_EAST_BLOCK)(MAX_NORTH_BLOCK) 
[RAY  J»ROC_MAX)[RES_RANGE^NUM]y*Map  of  terrain 
data  in  the  HSPVG  ray  trace  processors. 

Dimensions  are: 

•easting  quarter  kilometer  block  numbers 
-northing  quarter  kilometer  block  numbers 
-ray  processor  number 
-resolution  ranges 

for  each  resolution  range  a  16  bit  value  is  stored 
with  the  following  meaning 
bit  IS  Bits0tol4  description 
0  Ono  data  no  need 
1  Ono  data  but  needs  it 
0  block#has  data  no  need 
*  block#  has  data  and  needs  it 
•/ 
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u.short  TEILPROC.SENDtRAY_PROC.MAX+l)(MAX.BLOCK64K4): 

I*  Terrain  processor  send  list  Diinensk)r.s  are 

•HSPVO  processor  number  were  dau  is  to  come  from 

0- SUN  processor 

•list  entry  index  sized  to  allow  a  full 

of  every  quarter  kilometer 

[][][0}'destination  processor  number 

if  >1  means  delete  this  terrain  data 

QD[l]<easting  block  number  of  data  to  be  sent 

QQ[2]'notthing  block  number  of  data  to  be  sent 

Q[][3]'resolution  of  data  to  be  sent*/ 

u.short  SEND(RAY_reOC_MAX+l)'y*  list  entry  pointer  for 
TER_PROC_SEND  contains  the  number  of  blocks 
‘  ''nx:essor  needs  to  send. 


/•♦••••.••,*********yAROET  data  base  declarations*********************/ 

int  TARGETLIST(MAX_TARGETS)[10)y*  target  information  list 
(Ol-target  type  ID 

[1] seasting  position  of  target  in  meters 

(2] Bnorthing  position  of  target  in  meters 
[31a>altitude  position  of  target  in  meters 

(4] b  target  heading  in  millirads  clockwise  from  north  ng 

(5] b  target  pitch  in  millirads  positive  up 

(6] >  target  roll  in  millirads  clockwise  positive 

(7] b  speed  in  millimeteis/sec 

(8] b  status 

(9] b  spare  conriguration  parameter*/ 
struct  HAVELISTEL  ( 

unsigned  char  *TAR_PTR;  /*  pointer  to  target  data  in  memory  */ 
int  RES;  /*  resolution  index  of  target  data  */ 

I  HAVELISTIMAX.TARGETS];  /•  list  of  daL>  in  SUN  memory  */ 

/*SUN  resident  target  file  buffers.  These  buffers  are  sized  to  hold 
entire  target  file  for  a  binary  write*/ 
unsigned  char  TARBUFl[MAX_TARl]rrARl_SIZE): 
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r  I’s  resolution  SUN  resident  target  buffer  */ 
unsigned  char  TARBUF2[MAX.TAR2][TAR2.SIZE]; 
r  2*nd  resolution  SUN  resident  target  buffer  */ 
unsigned  char  TARBUF3[MAX_TAR3][TAR3_SIZE1; 

/*  3'd  resolution  SUN  resident  target  buffer  */ 
unsigned  char  TARBUF4[MAX_TAR4][TAR4_SIZE]: 

/*  4'th  resolution  SUN  resident  target  buffer  */ 

int  TAR^SEND_LIST[MAX_TARGETS)(4];r  list  of  data  to  be  sent  to  the 

target  processor 

(0]a>source  of  data  processor  ID 

(llsdestination  of  data  processor  ID 

[2] BSOurce  data  start  address  of  data  packet  (UNUSED) 

[3] snumber  of  data  elements  to  send*/ 

unsigned  char  •TAR_SEND_UST_PTR(MAX_TARGETS); 
r  replaces  (2J  of  above  •/ 

int  TAR_HAVE_LISTIMAX_TARGETS][20)y*  infonnalion  block  buffer 
used  to  collect  and  store  information  about  what  data 
the  target  processor  has. 

[Olstarget  type  ID 
>0  target  type  ID 

<0  player  not  needed  or  not  in  field  of  view 

(1] Beasting  position  of  target  in  meters 

(2] snorthing  position  of  target  in  meters 

(3] «altitude  position  of  target  in  meters 

(4] a  target  heading  in  milliradians  clockwise  from  northing 

(5] a  target  pitch  in  milliradians  positive  up 

(6] b  target  roll  in  milliradians  clockwise  positive 

(7] «  speed  in  meterg/sec 

(8] b  status 

(9] «  spare  configuration  parameter*/ 

/*[I0]adata  transfer  instruction  parameter 
■0  no  change 

■1  delete  old  view  data 

-2  delete  old  view  data  and  add  new  data 

(I  l]>v;ew  resolution 

[12] aieso!ution  linear  atray  dimension 

[13] Bview  heading  milliradians 

[14] Bview  pitch  milliradians 

[15] aview  roll  milliradians 
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[16]b  image  center  in  column  pixels,  i 
[17H  image  center  in  tow  pixels,  j 
[18]b  image  scale  in  pixels  per  millimeter 
[191«  spare  view  parameter*/ 

int  NUM_TAR_TRIAL;  /•  number  of  targets  in  trial  */ 


FUOHT  DECLARATIONS 

int  FLIGHT_CHAR(10]/*  Missile  flight  characteristics 
(0]«  flight  speed  in  meten  per  second 

[1] >tun)  rate  in  degrees  per  second 

[2] «launch  acceleration  in  meterv'sec/sec 

[3]  to  [9] -undefined*/ 

int  1FOVNOW[IO]/*  instantaneous  field  of  view  vector 
(Ol-easting  position  of  camera  in  meten 

(1] -northing  position  of  camera  in  meten 

[2] >altitude  position  of  camera  relative  to  sea  level 

(3] -boresight  direction  heading  clockwise  from 
northing  axisfmilliradians) 

[4] -boiesight  direction  pilch  positive  up  from 
horizontal  planefmillimdians) 

(Sl-field  of  view  roll  about  boresight  vector 
clockwise  positive  looking  out(millirads) 

(6]-zoom  factor  in  milUiadians 
(71-curser  location,  x  pixek  in  upper  word 
y  plxeb  in  lower  word 
[81-auto  pilot  control  status, 

Oaipre  launch 

1- launch  under  auto  pilot  control 

2- fUghi  under  auto  pilot  control 

3- flight  no  autopilot 

4- flighi  lock  on  target 

5- crash  no  signal 
(9)-  spare*/ 
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int  iroV_PRBDICTlPREDICT_INT_MAXl[8];/*  IFOV  predict  matrix 
[0]a«asting  position  of  missile  in  meters 

[1] >n(xthing  position  of  missile  in  meten 

[2] Baliitude  position  of  missile  in  meters 

[3] «  easting  velocity  direction  cosine 

[4] b  noething  velocity  direction  cosine 

[5] a  vertical  velocity  direction  cosine 

[6] >  qteed  in  meten/sec 
[?]■  autt^ot  control  status 
Ospre  launch 

lalaunch  under  auto  pilot  control 
2aflight  under  auto  pilot  control 
3«flight  no  autopilot 
4«flight  lock  on  target 
S>ciash  no  signal*/ 

int  PREDICr_INTIPREDICT_lNT_MAXiy*  Predict  interval 
array  in  seconds.  */ 

int  WAYPOINTS[WAYPOINT_MAXJ(3)’y*  point  coordinate  vectors*/ 

int  LOCK_POS_IMAGE(3];  /*  target  lock  position  and  status  in 

image  coordinates  returned  to  PVG  from  flyout  model 

[0]  ■  pixel  row  count 

[  1]  ■  pixel  column  count 

[2]  B  lock  status  <0  not  locked,  >0  locked*/ 

int  LOCK_POS_UTM[4];  /*  target  or  terrain  position  and  status 

of  locked  on  pixel  location  sent  to  flyout  model 

fitHn  PVG  in  UTM  coordinates 

[0]-  easting  in  meters 

II]  ■  northing  in  meters 

[2]  ■  altitude  in  meters  from  sea  level 

[3]  ■  miss  distance  from  closest  target  if  zero  lock 
on  identified  target  otherwise  it  is  locked  on 

a  terrain  feature*/ 
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/•••••••••••••••••••OUTPUT  IMAGE  PARAMETERS  DECLARATIONS**************/ 

ini  OinPUT_IMAGElPVG^HEIGHT](PVG_WlDTH]./*  output  image  buffer 

bits  0  to  7  red 

bits  8  to  IS  green 

bits  16  to  23  blue 

bits  24  to  31  alpha*/ 

/*  THIS  WILL  NOT  WORK! !  YOU  PLOT  A  COLOR  INDEX.  NOT  AN  RGB  VALUE.  */ 

short  RAY_SEG[RAY_PROC_MAX]t4]y*  ray  trace  calculation  image 
window  definitions  the  first  dimension  is  the 
processes  number,  the  four  parameters  rqnesent 
0>  lower  left  row 
1>  lowCT  left  column 
2b  upper  right  row 
3b  upper  right  column*/ 

u.shon  TAR_OUTIPVG_HEIGHT)PVG_WIDTH][2]: 

/*  Target  PVG  output  array 
[0)a  gray  shade 
(1]b  slant  range*/ 

int  TER_GUTIPVG_HEIGHT][PVG_WIDTH1I2]: 
r  Terrain  PVG  ray  trace  output  array 
[01«  terrain  data  base  element 
[1]b  slant  range*/ 

u_char  RLUT[RLUT_BYTES]/*  Rendering  lookup  table  converts  terrain 
data  base  and  environmental  parameters  to  gray  shade*/ 

u.char  ATTLUT[ATTLUT^BYTES)‘7*  Attmospheric  aae.iuation  lookup*/ 

/•••••..•.•••••••••••/^j^UjjISTRATIVE  software  DECLARATIONS*************/ 

/••••••••••••••••••••f^f^ORY  MANAGEMENT  DECLARATIONS*******************/ 

/•••••••••••••••••••••T^C  board  PARAMETERS  DECLARATIONS**************/ 

/••••••••.••••••••••••){3pyQ  hardware  PARAMETERS  DECLARATIONS**********/ 

#endif 
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♦ifhdef  P  VG.INCLUDBD 
♦define  PVG.INCLUDED 

^••**************************«***«***«****«*****««*«*>*»»»«***»»»««i*»*«*«* 

FILENAME:  PVG_DEC.IN 

PURPOSE:  GLOBAL  PARAMETER  DECLARATION  FILE  FOR  PVG  ALGORITHMS 

DESCRIPTION:  The  PVG.DEC.IN  include  file  includes  all  global  variables 
required  for  sharing  data  between  mtgor  software  components  of 
PVG  software. 

Parameters  are  divided  into  m^jor  categories  using  asteric  lines. 

All  global  variables  shall  be  ALL  CAPITAL  letters. 

USE  EXAMPLE: 

♦include  <PVG_DEC.IN> 

♦include  “PVG.DEF.IN" 

f*m*»0*mm*»***»m**  COLOR  PARAMETERS  DECLARATIONS***********************/ 

/•••♦•••••••••••••••terrain  data  base  declarations*********' 

/*  Sun  main  memory  teiraiii  storage  buffers*/ 

extern  u_int  1  bKRAIN  1  [MAX_BLOCK  1 )  [BLOCK  1_SIZE)  ;/*one  meter 
terrain  buffer*/ 

/*  Terrain  data  bit  assignments  valid  for  all  resolutions: 

32  1 

10987654321098765432109876543210 
I ELE I  SPARE  I  NOR  ISI VEG  I GSV  I 


where: 

ELE  *  elevation  from  sea  level  to  top  of  vegetation  in  meters 
SPARE  >  not  used 
NOR  »  4  bit  surface  normal 
S  ■  sun  shade  bit 
GSV  a  gray  shade  value 
*/ 
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extern  int  TERRAI^n^IAPtMAX_EAST_BLOCK][MAX_NORTH_BLCX:K];/•  terrain  map 
contains  pointers  to  temin  data  bkxks*/ 

extern  int  HAVEMAP[MAX_EAST_BLOCKl[MAX_NORTH_BLOCKiy*  Teirain  resolution 
mi^  tells  what  resolution  blocks  are  in  memory*/ 


r  range  .Tsolution  parameters  */ 

extern  int  SRMIN(R£S„RANGE_NUM]y*minimum  resolution  in  metets  */ 
extern  int  SRMAX[RES„RANGE_NUMl;/*maxirimm  resolution  in  meters*/ 
extern  int  SRSTEP[RES_RANGE_NUM1;/*  step  size  in  meters*/ 


r  HSPVG  terrain  dau  management  •/ 

extern  int  IFOVGRID[MAX_EAST_BLOCK][MAX_NORTH_BLOCKl;r  Terrain  grid 
to  inutge  map.  Specifies  the  image  location  of 
ground  points. 

EX:  IFOVGRID[E][N]b  image  i  coordinate 

in  upper  wMd 

M  image  j  (row)  coordinate 

in  lower  word 

s  -1  if  terrain  point  is  not 

in  the  IFOV  image*/ 


/*  HSPVG  terrain  data  communication  variables*/ 

extern  u.short  TEILPR<X:_HAS[MAX_EAST_BL0CK1(MAX_N0RTH_BL0CK] 
(RAY  J»R(X:_MAXl[RES_RANGE_NUM]y*Map  of  terrain 
data  in  the  HSPVG  ray  trace  processor. 

Dimensions  are: 

•easting  quarter  kilometer  block  numbers 
•northing  quarter  Idlometer  block  numbers 
-ray  processor  number 
•resolution  ranges 

for  each  resolution  range  a  16  bit  value  is  stored 
with  the  following  meaning 
bit  IS  BitsOtoU  description 
0  Ono  data  no  need 
1  Onu  data  but  needs  it 
0  block#has  data  no  need 
1  block#  has  data  and  needs  it 
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V 

extern  u_shon  TER_PROC.SEND[RAY_PROC_MAX+l][MAX_BLOCK64][41: 

/*  Teri'uin  processor  send  list  Dimensions  are 

•HSPVO  processor  number  were  data  is  to  come  from 

0>  SUN  processor 

•list  entry  index  sized  to  allow  a  full 

of  every  quarter  Idloineter 

OQ[0]-destination  processor  number 

if  -1  means  delete  this  terrain  data 

□Qdl-easting  block  number  of  data  to  be  sent 

□Ql2]-northing  block  number  of  data  to  be  sent 

Dn[3]-resolution  of  data  to  be  sent*/ 

extern  u.shoit  SEND[RAY_PROC_MAX+l]‘y*  list  entry  pointer  for 
TER_PROC_SEND  contains  the  number  of  blocks 
each  processor  needs  to  send. 


^**«**«************T^(>£>p  declarations*********************/ 

extern  int  TARGETL1ST(MAX_TAJIGETS][10]'/*  target  information  list 
(0]s|arget  type  ID 

[1] aeasiing  position  of  target  in  meters 

[2] anotthing  position  of  target  in  meters 

[3] >altitude  position  of  target  in  meters 

[4] a  target  heading  in  millirads  clockwise  from  northing 

[5] a  target  pitch  in  millirads  positive  up 

[6] «  target  roll  in  millirads  clockwise  positive 

[7] *  speed  in  millimeters/sec 

[8] «  stanis 

[9] b  spare  configuration  parameter*/ 
extern  struct  HAVELISTEL  ( 

unsigned  char  *TAR_PTR:  /*  pointer  to  target  data  in  memory  */ 
int  RES;  /*  resolution  index  of  target  data  */ 

)  HAVEUST[MAX_TARGETS1:  /*  Ust  of  data  in  SUN  memory  */ 

/*SUN  resident  target  file  buffers.  These  buffers  are  sized  to  hold 

entire  target  file  for  a  binary  write*/ 

extern  unsigned  char  TARBUF1[MAX_TAR1)[TAR1_SIZE]: 
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r  I’s  resrdution  SUN  residem  ivget  buffer  */ 

extern  unsigned  char  TARfiUP2{MAX-TAR2](TAR2_SIZE]; 

r  2‘nd  restdution  SUN  resident  target  buffer  */ 

extern  unsigiwd  char  TARBUF3IMAX_TAR3]tTAR3_SIZEl: 

r  3’d  resolution  SUN  resident  target  buffer  */ 

extern  unsigned  char  TARBUF4[MAX_TAK4][TAR4_SIZE]; 

r  4*th  resolution  SUN  resident  target  buffer  */ 

extern  int  TAR_SEND_LlSTtMAX_TARGETS][4]y*  list  of  data  to  be  sent  to  the 

target  processor 

[0]BSOurce  of  data  processor  ID 

[1] Bdestination  of  data  processor  ID 

(2}<>:source  data  start  address  of  data  packet  (UNUSED) 

[3]>nuinber  of  data  elements  to  send*/ 

extern  unsigned  char  •TA1LSEND_UST_PTR[MAX_TARGETS]; 
r  replaces  (2)  of  above  •/ 

extern  int  TAR_HAVE_L1STTMAX_TARGETS)(20);/*  information  block  buffer 
used  to  collect  and  store  infonnaiion  about  what  data 
the  target  processor  has. 

[Ojetarget  type  ID 
>0  target  type  ID 

<0  player  not  needed  or  not  in  field  of  view 
( llaeasting  position  of  target  in  meters 

[2] anorthing  position  of  target  in  meters 

[3] »altitude  position  of  target  in  meters 

[4] b  target  heading  in  milliradians  clockwise  from  northing 

[5] «  target  pitch  in  milliradians  positive  up 
[61b  target  roll  in  milliradians  clockwise  positive 

(7] b  speed  in  meters/sec 

(8] b  status 

(9] b  spare  configuration  parameter*/ 

/*[10]adata  transfer  instruction  parameter 
>4)  no  change 

b1  delc-ie  old  view  data 

■2  delete  old  view  data  and  add  new  data 

[I  I]«view  restdution 

( 12] Biesoluticin  linear  anay  dimension 

(13] aview  heading  milliradians 

(14] sview  pitch  milliradians 
[ISjaview  roll  milliradians 


190 


[16] a  image  centa’  in  column  pixels,  i 

[17] b  image  center  in  row  pixels,  j 
118]b  image  scale  in  pixels  per  millimeter 
[19]>  spate  view  parameter*/ 

extern  int  NUM_TAR_TRIAL;  /•  number  of  targets  in  trial  •/ 


f*****»**mm^**»*m**mcAMERA  AND  FUGHT  DECLARATIONS 


extern  int  FLIGHT_CHAR(10];r  Missile  flight  characteristics 
[0]>  flight  speed  in  meters  per  second 

[1] >tum  rate  in  degrees  per  second 
{2]siaunch  acceleration  in  meters/sec/sec 
(3]  to  [9]  «  undeAned*/ 

extern  int  IFOVNOWflO];/*  instantaneous  field  of  view  vector 
(Ojaeasting  position  of  camera  in  meters 
(IJanotthing  position  of  camera  in  meters 

[2] saltitude  position  of  camera  relative  to  sea  level 

[3] Bboresight  direction  heading  clockwise  from 
northing  axisfmilliradians) 

[4] Bboresight  direction  pitch  positive  up  from 
horizontal  plane(milliradians) 

[Sjafield  of  view  roll  about  boresight  vector 
clockwise  positive  looking  outfmillirads) 

(6] BZOom  factor  in  milliracUans 

[7] acurser  location,  x  pixels  in  upper  word 
y  pixels  in  lower  word 

[gjaiauto  pilot  control  status, 

Oaipre  launch 

lalaunch  under  auto  pilot  control 
2«flight  under  auto  pi!  )t  control 
3>flight  no  autopilot 
4Kflight  lock  on  target 
5-crash  no  signal 
[9)»  spare*/ 
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cxtem  int  IF0V_PREDICnPREDICT_INT_MAX][8]y*  IFOV  predict  matrix 
[0]aeasting  position  of  missile  in  meters 

[1] xnoEthing  position  of  missile  in  meters 

[2] Kaltitude  position  of  missile  in  meters 

[3] «  easting  velocity  direction  cosine 

[4] b  northing  velocity  direction  cosine 

[5] «  vertical  velocity  direction  cosine 

[6] a  speed  in  meters/sec 

[7] b  autopilot  control  status 
Ospre  launch 

lelauitch  uitder  auto  pilot  control 
2aflight  under  auto  pilot  control 
Saflight  ito  auU^iot 
4sflight  lock  on  target 
Sacrash  no  signal*/ 

extern  int  MIED1CT_INT[PREDI  _T_INT_MAX]  ./*  Predict  interval 
array  in  seconds.  */ 

extern  int  WAYPOINTS[WAYP01NT_MAX][3iy*  point  coordinate  vectors*/ 

extern  int  LOCK_POS_IMAGE(3];  /•  target  lock  position  and  staivs  in 
intage  coordinates  returned  to  PVG  from  fl yout  model 
[0]  ■  pixel  row  count 

[1]  a  pixel  column  count 

[2]  a  lock  status  <0  not  locked,  >0  locked*/ 

extetTi  int  LOCK_POS_UTMi‘  ];  /•  target  or  terrain  position  and  status 
of  locked  on  pixel  location  sent  to  flyout  model 
from  PVG  in  UTM  coordinates 
[0]a  easting  in  meters 

[1]  a  northing  in  meters 

[2]  a  altitude  in  meters  from  sea  level 

[3]  a  miss  distance  from  closest  target  if  zero  lock 
on  identined  target  otherwise  it  is  locked  on 

a  terrain  feature*/ 


192 


r 


•OUTPUT  IMAGE  PARAMETERS  DECLARATIONS 


extern  int  OUTPUTJMAGEtPVG.HEIGHDlPVG.WIDTH];/*  output  inwge  buffer 

bits  0to7  red 

bits  8  to  IS  green 

bits  16  to  23  blue 

bits  24  to  31  a4>ha*/ 

r  THIS  WILL  NOT  WORK!!  YOU  M-OT  A  COLOR  INDEX,  NOT  AN  RGB  VALUE.  V 

extern  short  RAY_SEGfRAY_PROC_MAX]I4];/*  ray  trxe  calculation  image 

window  definitions  the  first  dimension  is  the 

proces.<ior  number,  the  four  parameters  represent 

0*  lower  left  row 

N  lower  left  column 

2>  upper  right  row 

3«  upper  right  column*/ 

extern  u.short  TAR.OUTIPVG  .HEIGHT]  [PVG.VtTDTH]  (21; 

/*  Target  PVG  output  array 
[0]b  gray  shade 
[1)«  slant  range*/ 

extem  int  TER_OUT(PVG_HEIGKT][PVG_WIDTH](2]; 

/•  Terrain  PVG  ray  trace  ou^t  array 
[0]>  terrain  data  base  element 
[l]s  slant  range*/ 

extern  u..char  RLUT(RLUT_B YIES];/*  Rendering  lookup  table  converts  terrain 
data  base  and  environmental  parameters  to  gray  shade*/ 

extern  u_char  ATTLUTlATTLUT_BYTES)y*  Attmospheric  attenuation  lookup*/ 


software  DECLARATIONS***** 
MANAGEMENT  DECLARATIONS*********' 

BOARD  PARAMETERS  DECLARATIONS****** 

'HSPVG  HARDWARE  PARAMETERS  DECLARATIONS 


#endif 


♦ifndcf  P  VG.DEF.INCLUDED 
#<fcfinc  PVG_DEF_INCLUDED 

. . . . 

FILENAME:  PVG.DEF.LARGE 

PURPOSE:  GLOBAL  PARAMETER  DEFINITION  FILE  FOR  PVG  ALGORITHMS 

DESCRIPTION:  The  PVG_DEF.IN  include  file  includes  all  global  constants 
required  for  defining  global  constants  used  by  PVG  software 
components. 

Parameters  are  divided  into  major  categories  using  asteric 
lines. 

All  global  constants  shall  be  ALL  CAPITAL  letters. 

USE  EXAMPLE: 

#include  "PVG.DEF.IN" 

in  your  directory  link  to  /home/fogm/include/PVG.DEF.IN 

•*«***«*««*«******«*«****«**(^q£START*************************'‘******V 

#include  <FOGM/stdef.h>  Tstandard  definitions  */ 

r#include“stdef.h"*/ 

iinclude  <sysAypes.h> 

^«««**,.**«,***«*  COLOR  PARAMETERS  DECLARATIONS***********************/ 

base  DECLARATIONS********************/ 

/*  Sun  main  memory  lenain  storage  buffers*/ 

/*  terrain  data  blocks  all  cover  a  2S6meterx2S6  meter  area*/ 

#derine  MAX.BLOCKl  4  /*  #  one  meter  terrain  BLOCKl_SIZE*4byte  blocks*/ 
idefine  BLOCK  l_SiZE  65536  /*  #  elements  in  1  meter  block  */ 

#define  MAX_BLOCK4  1024  /*  #  4  meter  terrain  BLOCK4_SIZE*4byte  blocks*/ 
idefine  BL0CK4_S1ZE  4096  /*  i  elements  in  4  meter  block  */ 

idefine  MAX_BLOCK16  14336  T  i  16  meter  terrain  BLOCK  16_SlZE*4byle  blocks*/ 
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«<fefine  BIjOCK16.SIZE  256/*#  efements  in  16  meter  block  •/ 


idefine  MAX_BLOCK64  14336  /*  #  64  meter  terrain  BLOCK64.SIZE*4byte  blocks*/ 

#<lerine  BL0CK64_S12  16  /*  #  elements  in  64  meter  block  */ 

ideflne  MAX_BLOCK256  14336  T  #  2S6  meter  terrain  4byteblocks*/ 

»derine  MAX.EAST.BLOCK  128  /*  #  256  meter  blocks  in  east  direction*/ 

»derine  MAX_NORTH_BLOCK  1 12  /*  «  256  meter  blocks  in  nonh  direction*/ 

#define  MIN_EAST_IJTM  43328  /*  lower  left  hand  comer  of  data  base  UTM  east*/ 

#define  MIN.NORTH.UTM  63904  T  lower  left  hand  comer  of  data  base  UTM  north*/ 

/*  Range  resolution  parameters  */ 

#dcfine  RES_RANOE_NUM  4  /•  #  resoluuon  ranges  */ 

/*  Resolution  codes  */ 

#define  RESOLUTION.!  0 
«defineR£SOLUTION_4  1 
«derine  RESOLUTION.16  2 
#define  RESOLUTION_64  3 

^••*»«*****«***«***TARGET  data  base  DECLARATIONS*********************/ 

/*  SUN  target  data  buffets*/ 

#deftne  MAX.TAROETS  256/*  Maximum  number  of  targets  in  PVG*/ 

#derine  MAX_TAR.TYKE  32/*Maximum  number  of  different  targets*/ 

#derine  MAX.TARl  ST  Maximum  number  of  target  types  in  I'st 
resolution  level*/ 

#deflne  MAX_TAR2  8/*  Maximum  number  of  target  types  in  2’nd 
resolution  level*/ 

#define  MAX_TAR3  8/*  Maximum  number  of  target  types  in  3'd 
resolution  level*/ 

^define  MAX_TAR4  8/*  Maximum  number  of  target  types  in  4'th 
resolution  level*/ 

#deflne  TARI.SIZE  1069056/*  Buffer  size  in  bytes  for  64pictures  of  1  *st 
resolution  level*/ 

#derine  TAR2_SIZE  282624/*  Buffer  size  in  bytes  for  64  pictures  of  2'nd 
resolution  level*/ 

#deftne  TAR3_SIZE  86016/*  Buffer  size  in  bytes  for  64  pictures  of  3’d 
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resolutkx)  level*/ 

#<}eflne  TAR4_SIZ£  36864/*  Buffer  size  in  bytes  for  64  pictures  of  4*ih 
resolution  level*/ 

^►••♦••••••♦•♦••••♦♦CAMERA  AND  FLIGHT  . . *•*•/ 

#<fcrine  PREDICT_INT_MAX  4  /•  Number  of  IFOV  predict  intervals*/ 

#<lerute  WAYPOINT_MAX  2i>  /*  Maximum  #  way  point  coordinate  vectors*/ 

yi»**«*««*,«****«»*»*OIJTPUT  IMAGE  PARAMETERS  DECLARATIONS**************/ 

tdefuie  PVG.HEIGHT  256  /*  output  image  M  pixel  tows*/ 

#denne  PVG_W1DTH  256  /*  output  image  #pixel  columns*/ 

#denne  PVG_PIX_SIZE  65536  /*  output  image  size  in  pixels*/ 

#define  RLUT_BYTES  2097152  /*  #  bytes  in  the  RLUT*/ 

#define  RLUT.BIT.SIZE  21  /*  #  bits  in  RLUT  input  adders*/ 

#deruie  VIEW.INDEX.SIZE  3  T#  bits  in  view  vector  of  the  RLUT  input  address*/ 
idefuie  NORM_INDEX_SI2X  4  /*<!  bits  in  surface  normal  of  the  RLUT  input  address*/ 

#define  ATTLUT.BYTES  2097152  /*#  bytes  in  attenuation  table  ATTLUT*/ 

#deflne  ATTLUT_BIT_SIffi  21  /•  #  bits  in  ATTLUT  input  address*/ 

#deflne  TAR_V1S_MASK  255  /*if  target  gray  shade  is  2^  5  let  background  through  */ 

^♦.••••••••.•••••••♦.^^(INisTRATIVE  SOFTWARE  DECLARATIONS*************/ 

ideflne  D2R  0.0174532  /*  degrees  to  radians  */ 

Udefine  D2MR  17.4532  /*  degrees  to  milliradians  */ 

#define  R2D  57.295827  /*  radians  to  degrees  */ 

«define  MR2D  0.057295827  /*  milliradians  to  degrees  */ 

MANAGEMENT  DECLARATIONS********* . / 

Mdefute  MAX.SEND  14336  /*  maximum  number  of  messages  in 
TER_PROC_SEND  */ 


;»*«*«****************Yy^(;  BOARD  PARAMETERS  DECLARATIONS**************/ 
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HSPVO  HARDWARE  PARAMETERS  DECLARATIONS 


7 


^«***«i 

idefine  RAY_PROC_MAX  1  /*  maximum  #  ray  (race  procesaors  */ 
ideflne  TAR_PROC_MAX  1  /•  maximum  #  target  processon  V 

«endif 
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*  (C)  Copyright  Nascent  Systems  Development  Inc.  1991 

*  Developed  under  contract  DABT62*90^<0006,  Subcontract  CSC/AID-WR-FO-OlOl 

•/ 

FILENAME:  get.terr 
A1JTHOR:  J.R.  Akin,  August  1989 

PURPOSE:  Read  a  block  of  terrain  data  into  a  specified  buffer  location 
which  is  stored  in  SUN  main  memory.  The  block  needed  has  a 
lower-left  comer  at  DB  coordinates  x,  y. 

DESCRIPTION: 

Opening  and  closing  files  eats  up  a  lot  of  time.  Ideally,  this  function 
should  open  up  every  file  at  nart-up  but  it  can't  because  the  number  of 
files  that  can  be  opened  at  one  time  is  60  and  the  number  of  PVDB  Ales 
is  83.  Since  other  functioru  will  open  up  who-knows-how-many  files.  I’ve 
set  the  open  file  limit  to  MAX.JILE_HANDIJES.  an  arbitrary  value.  Files 
ate  opened  and  usage  statistics  maintained  until  the  file  handle  list  is 
exhausted,  at  which  point  tlie  least  often  used  file  is  closed,  and  a  new 
file  is  opened  to  take  its  place. 

Instead  of  using  time-wasting  string  comparisons  for  file  opens,  a  list 
of  hash  values  for  file  names  is  maintained.  The  hash  value  for  a  file 
is  computed  as: 

hash.value  ■  (resolution_code  «  8)  I  dle.number 

This  way,  time  can  be  saved  by  not  using  nested  “iP  siaiemenu  to 
determine  disk  partition  numben. 

Processing  Steps: 

make  sure  the  x,y  coordinates  are  in  bounds 
based  upon  the  resolution  code 
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compute  the  block  length 

set  the  date  block  pointer  to  the  starting  address  of  the 
appropriate  (global)  TERRAIN  buffer 
compute  the  die  number 
compute  the  block  number 
I 


compute  the  hash  value  based  upon  the  tile  and  block  number 

if  the  file  with  this  hash  value  is  already  open 

I 

get  the  file  handle  for  it 

increment  the  numbn'  of  times  this  file  handle  has  been  used 

1 

else 

I 

find  least  used  file  handle 

if  there  is  already  an  open  file  associated  with  it 
close  the  file 

open  a  new  file  for  this  file  handle  index 

set  number  of  times  file  handle  has  been  used  1 

I 


compute  file  offset  for  block  number 
seek  to  that  file  offset 

compute  the  number  of  bytes  that  need  to  be  read 
read  the  block  into  the  anviy  referenced  by  buflndex 
return  number  of  elements  successfully  read 

I 
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RETURN  VARIABLE:  Reoims  number  of  elements  successfully  loaded,  else  ERROR. 


REQUIRED  INCLUDE  FILES: 

PVO.DECJN 

PVG_DEF.IN 

LIBRARIES  REQUIRED: 


INPU'i  A)UTPUT  FILES:  use  name  description 
EXTERNAL  PARAMETERS:  use  nante  include  description 


Sun  main  memory  tenain  storage  buffen  (declared  in  PVG.DEC.IN)  updated 
by  get_tenO  and  called  by  tstwter.c.  MAX.BUXK  sizes  are  declared  in 
PVG.DEF.IN. 

lOTERRAINl  [MAX.BLOCKI]  [BLOCKl.SIZE] 

10  TERRAIN4  (MAX_BL0CK4)  (BL0CK4_SIZE] 

IOTERRA1N16  [MAX_BL0CK16]  [BLOCK  I6_SIZE] 

IOTERRAIN64  [MAX.BLOCK64]  [BLOCKM.SIZEJ 

FUNCnONS/SUBROUTINES  CALLED:  None. 

USAGE  EXAMPLE: 


get_terr_8tat  ■  get_tert(  RES0LUT10N_I,  s,  y,  bufindex  ); 

This  call  reads  a  quaiter  kilometer  (block)  of  l*meter  data  at  location 
index  x.y  and  puts  it  into  TERR  AINn[buru)dex]. 
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CODESTART*** 


iincIiKk  "PVO.DEF.IN” 

#inclii(le  "PVO.DBC  JN" 

#include  <itdk>.h> 

#include  <fcntLh>  r  for  binary  VO  */ 

«define  MAX_FILE_HANDLES  32 

♦define  MAX_PVDB^FE^  83 
♦define  MAX_FILE_NAME 32 

♦define  MAX_PVDB_EAST  32767 
♦define  MAX_PVDB_NORTH  28671 

♦define  UNUSED -1 


int  get.ient  res.code,  x,  y.  bufindex ) 

int  res.code;  /*  Resolution;  1, 4, 16,  or  64  •/ 
int  X.  y;  terrain  map  coordinate  indices  */ 
int  bufindex:  /*  buffer  index  of  block  to  be  read  */ 

I 

extern  unsigned  intTERRAINl  [MAX.BLOCKl]  [BLOCK I.SIZE); 
extern  unsigned  int  TERRA1N4  (MAX.BLOCK4]  (BLOCK4_SIZE]; 
extern  unsigned  int  TERRAIN16  [MAX_BLOCKl6]  [BLOCK16_SIZ£]; 
extern  unsigned  int  ‘rERRAV464  [MAX_BLOCK64]  [BI.OCK64_SIZE]; 


/*  Actual  file  names,  only  used  for  openQ  */ 

static  char  file.name  [MAX_PVDB_FILES]  (MAX_FILE_NAME_LEN]  - 

[ 

“A>vdb_data^vdb.64’’,  “^vdb_data^vdb.l6". 

“^vdb_data^vdb.4.00",  “^vdb_data/pvdb.4.01’’,  “/pvdb_dat^vdb.4.02'’, 
“/lpvdb_data/i)vdb.4.03”,  “^vdb_data/pvdb.4.04",  “/pvdb_data/pvdb.4.05’'. 
“/lpvdb_daiayi)vdb.4.06".  “/Ipvdb.data/pvdb^.  10”.  “/pvdb_data/pvdb.4. 1 1". 
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“A)vdb_dai«/i>vdb.4.12’*,  “^vdb.d«a/pvdb.4. 13".  ••/pvdb_dala/pv<lb.4. 14". 
“^vdb_din^vdb.4.15".  ‘‘/j;)vdb_daiVpvdb.4.16".  "/i>vdb_data/j)vdb.4.20". 
"/frvdb.diia/Mb.dil".  ‘*/lpvdb_<hu/pvdb.4.22".  ••/pvdb_daia/i)vdb.4.23". 
“^db_dal*^)vdb.4^".  *'^vdb_dati^ivdb.4.2S".  "/pvdb_dan/pvdb.4.26". 
“A>vdb.daia4>vdb.430".  “/i»vdb_datt/Jjvdb.4.31".  “/pvdb_data/pvdb.4.32". 
"^vdb_dau^vdb.4.33".  “/pvdb_dao^db.4.34".  “^vdb_dati^v(B).4.35". 
“^vdb.daJa^db.d^d".  “/pvdb_dai^^db.4.40".  “/pvdb_daWpvdb.4.41". 
‘‘A>vdb„data4>vdb.4.42".  ‘*^vdb_datVpvdb.4.43".  “/t»vdb_dal«/pvdb.4.44". 
“y^vdb_daia^vdb.4.45".  “/|pvdb_dai*/pvdb.4.46".  “/i>vdb_dan/pvdb.4.50". 
“A>vdb_data/i»vdb.4.5r.  “/Ipvdb_d8ta/pvdb.4.52".  ••/pvdb_dau/pvdb.4.53". 
“/i)vdb.data/i>vdb.4^".  “A)vdb_dau/pvdb.4.55".  “A)vdb_datt/pv<lb.4.56". 
“A>vdb_da6»^>vdb.4.60".  “^vdb_datt/pvdb.4.61".  “/pvdb_dat^vdb.4.62". 
“^vdb_daia4>vdb.4.63".  “^vdb_dat^)vdb.4.64".  “/pvdb_dau^vdb.4.65". 
‘‘^vdb_dai«^vdb.4.66".  “^vdb_(laia/pvdb.4.70”.  “/pvdb_dau^vdb.4.71", 
“A>vdb_daia/i)vdb.4.72".  ‘*/lpvdb_data^db.4.73".  •7pvdb_daia/pvdb.4.74". 
“^vdb_data^vdb.4.75".“^vdb_dam/pvdb.4.76". 

“/Ipvdb_datt/Mb.  113".  “/Ipvdb.dau/iwdb.  1 . 14".  "/pvdb.datt/pvdb.  1.15". 
“/i>vdb_datt/t>vdb.l.22".  “/jpvdb_dau/pvdb.l.23".  ‘‘/pvdb_datt/pvdb.l.24". 
"A)vdb_diia/i)vdb.l.25".  •‘/i>vdb_dau»^db.l.31".  “/pvdb_dau/pvdb.l.32". 
“^vdb_daia^vdb.l.33",  “4>vdb_dsii^db.l.34".  ''/pvdb.daiVpvdb.l.3S". 
“/frvdb_daia^)vdb.l.41",  •‘^db_dau»/J)vdb.l.42".  “/pvdb_datt^vdb.l.43". 
“^vdb_dai»^db.l.44".  “^db_d»a^db.l.45".  “^vdb_dau^vdb.l.51", 
“yi>vdb_daia/i)vdb.l  J2".  ••yi)vdb_dai^vdb.l.53".  “/pvdb_data/pvdb.l,$4". 
“/i)vdb_dMa/t>vdb.l.61".  “/i>vdb_daWpvdb.l.62".  “/pvdb_dau/pvdb.l.63". 
"/J)vdb_datt/i>vdb.l.64" 

I; 


/*  Hash  values  for  file  names  *! 

static  int  file^nainc_hash_valuc  [MAX_PVDB_F1LES]  ■ 

{ 

(RESOLUnON_64«8)IOxOO. 

(RESOLUnON_16«8)l03iOO. 

I*  4-meter  files  •/ 

(RESOLUnON_4«8)IOxOO.  (RESOLUnON_4«8)IOx01.  (RESOLirnON_4«8)IOx02. 
(RESOLUnON_4«8)IOx03.  (RESOLUnON_4«8)K)x04.  (RESOLUnON_4«8)10x05. 
(RESOLUnON_4«8)K)x06. 
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(RBSOLimON^4«8)IOxlO.  (RBSOLUTION.4«8)IOxll,  (RESOLUnON.4«8)IOxl2. 
(RBSOLUnON_4«8)l03tl3.  (RESOLimON_4«8)K)xl4.  (RESOLimON_4«8)IOxlS. 
(RESOHmON_4«8)»xl6. 

(RESOLirnON_4«8)IOx20.  (RESOLUnON„4«8)K)x21.  (RESOLimON_4«8)K)x22. 
(RESOLirnON_4«8)«Ox23.  (R£SOLUnON_4«8)IOji24,  (RESOLirnON_4«8)K)x25. 
(RESOLUnON_4«8)Kh26. 

(RESOLUnON_4«8)IOx30.  (RESOLUnON_4«8)IOx31,  (RESOLUnON_4«8)l03i32. 
(RESOLirnON_4«8)IOx33.  (RESOLUnON_4«8)K)x34.  (RESOLUnON_4«8)K)x35. 
(RESOLimON,4«8)IOx36. 

(RESOLimON_4«8)IOx40.  (RESOLimON_4«8)K)x41.  (RESOLimON_4«8)K)x42. 
(RESOLUTION_4«8)IOx43,  (RESOLUnON_4«8)K)3i44.  (RESOLUnON_4«8)K)x45. 
(RESOLimON_4«8)IOx46. 

(RESOLUnON_4«8)IOx50.  (RESOLimON_4«8)K)x51.  (RESOLimON_4«8)K)x52. 
(RESOLUnON_4«8)IOx53.  (RESOLUnON_4«8)K)x54.  (RESOLimON_4«8)K)x55. 
(RESOLimON_4«8)IOx56. 

(RESOLimON_4«8)»x60.  (RESOLimON.4«g)K)x61.  (RESOLimON_4«8)IOx62. 
(RESOLimON_4«8)IOx63.  (RESOLUnON_4«8)Kh64.  (RESOLUnON_4«8)K)x65. 
(RESOLimON_4«8)IOx66. 

(RESOLimON_4«8)Ox70.  {RESOLUnON.4«8)K))t71.  (RESOLUnON_4«8)K)x72. 
(RESOLimON_4«8)IOx73.  (RESOLUnON_4«8)IOx74.  (RESOLUnON_4«8)K)x75. 
(RESOLlJnON_4«8)IOx76. 

/•  1-meter  files  */ 

(RESOLUnON_l«8)l03il3.  (RESOLUnON_l«8)K)xl4.  (RESOHjnON_l«8)IOxl5. 

(RBSOLUnON_l«8)IOx22.  (RESOLimON_I«8)K)*23.  (RESOLUTION.  l«8)K)x24. 
(RESOLUnON_l«8)IOx25. 

(RESOLLrnON_I«8)10x31.  (RESOLUnON_l«8)K)x32.  (RESOLUTION.  l«8)K)x33. 
(RESOLUTION.l«8)»x34.  (RESOLUTION.l«8)K)x35. 

(RESOLUTION.!  «8)IOx4 1.  (RESOLUTION_I«8)K)x42.  (RESOLUTION_l«8)JOx43. 
(RESOLUTION_l«8)IOx44.  (RESOLUTION.  l«8)K)x45. 
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(RESOLUTION_l«8)IOx5l.  (RESOLUnON,l«8)Kh52.  (RESOLUnON_!«8)K)ii53. 
(RBSOLUnON_l«8)IO]t54. 

(RESOUjnON_l«8)IOx61.  (RESOLUnON_l«8)IOx62.  (RESOLinnON_l«8)IOx63. 
(RESOLUT10N_l«8)IOx64 
); 


!*  fde_(^)ened(n]  tells  whether  a  file  has  been  opened.  Static  storage  V 
/*  without  initilization  garauntees  that  elements  will  be  set  to  0  (NO)  */ 

static  iiit  fUe.opened  [MAX_PVL'B_FILES] « 

( 

UNUSED.  UNUSED, 

UNUSED.  UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED.  UNUSED, 

UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED. 

UNUSED,  UNUSED.  UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED. 

UNUSED.  UNUSED.  UNUSED.  UNUSED 

}; 

/*  List  of  fik  handles  used  for  I/O  */ 

static  int  fh  [MAX.FILE.HANDLES]  - 

( 

UNUSED,  UNUSED.  UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED.  UNUSED. 
UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 
UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 
UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED 
I: 
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I*  List  of  hash  value  indices  for  oftened  files  */ 


static  int  fh_hash_value_index  (MAX_FILE_HANDLES]  ■ 

I 

UNUSED.  UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 
UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 
UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 
UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED 
): 


static  int  fUe.usage  (MAX_FILE_HANDLES) » 

I 

UNUSED.  UNUSED.  UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED.  UNUSED. 
UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED.  UNUSED. 
UNUSED.  UNUSED.  UNUSED.  UNUSED,  UNUSED.  UNUSED.  UNUSED,  UNUSED. 
UNUSED.  UNUSED.  UNUSED,  UNUSED,  UNUSED.  UNUSED,  UNUSED.  UNUSED 
): 


static  int  fhJndex_to_use  *  0;  /*  file  handle  index  to  use  V 
int  tUe.num,  block.num;  I*  tile  and  block  numbers  */ 
int  hash.value; 

int  hash.index;  /*  hash  index  */ 
int  usage; 
int  min.usage; 
int  n; 

int  blockjength; 

unsigned  int  *bp:  r  block  pointer  •/ 
unsigned  int  file.ofTset; 
unsigned  int  bytes.to.read,  bytes.iead; 
int  elentents.read; 
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^••••••••***«*»**«****«***  bbGC'1  execution  ••••••••••« 

if(  X  <  0  H  X  >  MAX_PVDB_EAST ) 

{ 

fprintf(  stdout,  “get_ter.  X  coordinate  (%d)  (X)B\n",  x ); 
retuni(  ERROR ); 

) 

if(  y  <  0 II  y  >  MAX_PVDB_NORTH ) 

I 

^pnntf(  stdout,  “get.ter  Y  coordinate  (%d)  OOBNn”,  y ): 
retuin(  ERROR ); 

) 

if((x%256)!-0) 

I 

fpnntf(  stdout,  "get.ter  X  (%d)  not  an  even  multiple  of  256^”,  x ); 
retumf  ERROR ); 

) 

if((y%256)l=0) 

I 

fprintf(  stdout,  “gct_tcr  Y  (%d)  not  an  even  multiple  of  25®«",  y ); 
retufn(  ERROR ); 

) 

switchf  rcs_code ) 

I 

case  RESOLUTION.!; 
block.tength  -  BLOCK  l.SIZE; 
bp  ■  4TERRAINl[bufindex)I0]: 
bteak; 

default: 

fprintff  stdout,  “get.ler  Invalid  res.code  (%d)Nii".  res.code ); 
retumf  ERROR );  /*  invalid  resolution  •/ 

I 


/*  Tile  and  block  numbers  are  the  same  regardless  of  resolution  */ 
tile.num  ■  ((x»8)  &  OxFO)  I  (y»12); 
block.num  -  ((x»4)  &  OxFO) !  ((y»8)  &  OxF ); 
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t*  ...  but  Jie  hash  values  aen't.  The  16>  and  64-ineter  databases  ARE  */ 
/*  broken  into  tile  nuntben  but  they  aren’t  stored  in  multiple  files.  */ 

if(  res_co(«j  <  RESOLUnON_16 ) 
hash_value  ■  (res.code  «  8)  I  tik.num; 
else 

hash.value  ■  (res.code  «  8); 

I*  Find  the  index  to  the  file  name’s  hash  value  */ 

for(  hash_indLX»0;  hash_index  <  MAX_PVDB_FI1LES;  hash_index-M- ) 

I 

if(  hash.value  » tile_name_hash_value[hashjndex] ) 
break; 

I 

if(  hash.index  MAX_PVDB_FILES  )  /•  no  match  was  found  */ 

I 

fprintf(  stdout,  “No  data  available  at  %d,%d.  for  resolution 
».  y.  res.code ); 
retuin(  ERROR ): 

I 

if(  rile_opened[hash_index] !«  UNUSED )  /*  file  is  already  open  */ 

I 

/*  Get  the  proper  file  handle  and  increment  the  number  of  times  used  */ 

fh_index_to_use  ■  rile_opened[hash_index]; 
filc_usage[fh_index_to_use]++; 

I 

else  I*  this  file  needs  to  be  opened  */ 

I 

I*  Open  a  new  file.  Find  the  least  used  Hie  handle:  */ 

/*  if  it  is  used  (open),  close  it  first.  */ 

fh_index_to_use  »  &, 

min.usage  ■  file.usage(fh_indcx.io_u.<iel; 

for(  n-0;  n  <  MAX_FE.E_HANDLES:  n++  ) 

{ 

usage  m  nie.usag'fn]: 
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if(  usage  <  inifi_usage ) 

mtn.usage  ■  usage; 
fh_index_to_usc  •  n; 

) 

) 

if(  (hIfh_index_lo_use]  !■  UNUSED )  /•  close  it  first  */ 

I 

close(  fh(fh_in<lex_to_use] ); 

»  UNUSED; 

.opened!  fh_hash_vaIue_indcx(fli_in(lex_to„use]  ]  ■  UNUSED; 


/•  Open  the  new  file  •/ 

fh[fh_indcx_to_use)  *  open(  file_naine[hash_index).  0_RD0NLY ); 
if(  fh(fh_index_to_use)  ERROR ) 

I 

fprintf(  stdout,  “get.tcr  Can’t  open  fileVn" ); 
retuntf  ERROR ); 

1 

else 

{ 

file_opened[hash_index]  *  fh_index_to_use; 
file_usage(fh_index_to_usel  ■  1; 
ni_hash_vaIue_index(fh_index_to_use)  *  hash.index; 

I 

I 

/*  Compute  file  offset  for  this  block.num,  based  upon  the  tesolution  */ 
(*  and  seek  to  that  location.  */ 

switch!  res.code ) 

( 

caseRESOLUnON_l: 
case  RESOLUnON_4: 

filc_offsct  e  block.num  *  block.length  •  sizeof(  int ); 
break; 
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/*  For  16>  Hid  64>ineierreK)lutiont  compute  the  lik  lequence  number  */ 
number  (TUeji*7-fTik_jf),  multiply  it  by  the  number  of  elements  in  */ 
/*  a  die.  add  the  block  of&et  and  multiply  by  the  number  of  bytes  */ 

/•  in  an  int  •/ 

caseRESOLimON_16: 

caseRESOLUnON_64: 

file.offset  ••  ( ((tile_num»4)*7-f(tile_num&0xF)) 

•  (2S6*block^length)  +  (block_nuin*block_length) ) 

*  sizeof(  int ): 
break; 

} 


if(  lseek(  fhlih.index.to.use],  flle.offset,  0 )  n  ERROR ) 

I 

fprintf(  stdout,  Xan’t  seek  on  fil^” ); 
retuni(  ERROR ); 

) 

t*  Read  block  into  address  at  */ 

bytes.to.iead  ■  block.length  *  8izeof(  int ); 

bytes.read  ■  read(  fh(0i_index_to_usej.  (char  *)bp.  bytcs_to_read ): 

if(  bytes_read  !■  bytes.to.read ) 

( 

fiprintf(  stdout.  “Bad  read.  X:%d  Y:%d  res:%<fsn".  x.  y.  res.code ); 
fjprintf(  stdout.  “%d  bytes  read  instead  of 
bytc8_re£d.  bytes.tojead ); 
retunif  ERROR ); 

I 

elements.read  >  bytes.read  /  8izeof(  int ); 

. . 

tprintf(  stdout,  “X:%d.  Y:%Sd,  re8_code:%d  burindex:%d  address:  %06X\n“. 
X,  y,  res_code.  bufuidex.  bp ); 
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rttum(  elements.read ): 


) 

#iindef  MAXJTLE.HANDLES 
#undcf  MAX J»VDB_FILES 
#undef  MAXJTLB AME_LEN 
tundef  MAX J*VDB_EAST 
#undef  MAXJ»VDB_NORTH 
iundef  UNUSED 
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